Datenbank-Migration: Schema-Änderungen und Zero-Downtime Deploy
Datenbank-Migration ist der Prozess der sicheren und kontrollierten Anwendung von Schema-Änderungen. Dieser Leitfaden behandelt Migrationsstrategien, Zero-Downtime Deploy und Rollback-Pläne.
Aktualisiert:Was ist Datenbank-Migration?
Datenbank-Migration ist ein kontrollierter Prozess zur Änderung des Datenbank-Schemas (Tabellenstrukturen, Indizes, Constraints).
Schema-Änderungen: Neue Tabelle hinzufügen, Spalte hinzufügen/ändern/löschen, Index hinzufügen, Foreign Key hinzufügen, Datentyp ändern.
Risiken: Datenverlust, Downtime, Leistungsabfall, rückwärts inkompatible Änderungen.
Ziel: Schema-Änderungen sicher, wiederholbar und rollback-fähig anwenden.
Migrationswerkzeuge
Flyway: SQL-basiertes Migrationswerkzeug. Versionierte Migrationsdateien (V1__create_users.sql). Java, Node.js, CLI Support.
Liquibase: Changelog in XML/YAML/JSON/SQL Format. Rollback-Support, Diff-Generierung, Datenbankvergleich.
Prisma Migrate: Integriert mit Prisma ORM. Generiert automatisch Migration aus schema.prisma.
Knex.js: Node.js Migrationswerkzeug. Migrationsdateien in JavaScript. Up und Down Funktionen.
Django/ActiveRecord: Framework-eigene Migrationswerkzeuge. Erstellen automatisch Migration aus Model-Änderungen.
Zero-Downtime Migrationsstrategien
Expand and Contract (Parallel Change): 1) Neue Spalte/Tabelle hinzufügen (expand), 2) Code aktualisieren (neue und alte Spalte unterstützen), 3) Alte Spalte entfernen (contract).
Rückwärts kompatible Änderungen: Neue Spalte hinzufügen (nullable), neue Tabelle hinzufügen, neuen Index hinzufügen. Diese Änderungen erfordern keine Downtime.
Breaking Changes: Spaltenlöschung, Spaltentyp-Änderung, Umbenennung. Diese Änderungen sollten mit Expand-Contract Pattern durchgeführt werden.
Feature Flags: Neue Schema hinter Feature Flag stellen. Risiko mit schrittweisem Rollout reduzieren.
Blue-Green Deployment: Neues Schema in paralleler Umgebung testen. Traffic umleiten. Bei Problem zur alten Umgebung zurückkehren.
Datenmigration
Backfill: Bestehende Daten an neues Schema anpassen. Große Datenmengen mit Batch-Processing verarbeiten.
Dual Write: Sowohl in altes als auch neues Schema schreiben. Datenkonsistenz während Übergangsperiode beibehalten.
Datenvalidierung: Datenintegrität nach Migration prüfen. Row Count, Checksum, Sample Comparison.
Performance: Migration auf großen Tabellen erzeugt Lock und I/O-Last. Während Off-Peak-Stunden ausführen. Chunked Processing verwenden.
Rollback-Plan
Down Migration: Für jede Up Migration entsprechende Down Migration (Rollback) schreiben. Flyway, Liquibase unterstützen Rollback.
Backup: Vollständiges Backup vor Migration erstellen. Point-in-Time Recovery (PITR) Fähigkeit haben.
Testing: Migration in Staging-Umgebung testen. Gleiche Datenmenge und Schema wie Production verwenden.
Monitoring: Query-Performance und Error Rate nach Migration überwachen. Bei anormaler Abweichung rollback durchführen.
Kommunikation: Migrationsplan mit Team teilen. Maintenance Window (Wartungsfenster) definieren.
Best Practices
Version Control: Migrationsdateien mit Git verfolgen. Jede Migration sollte atomar (einzelne Änderung) sein.
Idempotency: Migration mehrmals ausführen sollte gleiches Ergebnis liefern. IF NOT EXISTS, IF EXISTS verwenden.
Kleine Migrationen: Große Änderungen in kleine Migrationen aufteilen. Jede Migration sollte unabhängig deploybar sein.
Code Review: Migrationsdateien durch Code Review schicken. Schema-Änderungen sind kritisch und schwer rückgängig zu machen.
Dokumentation: Zweck und Auswirkung jeder Migration dokumentieren. Breaking Changes klar kennzeichnen.