Was passiert nach einer erfolgreichen Datenbankmigration?

Eine Datenbankmigration läuft ohne Fehler durch. Die Pipeline zeigt grün. Das Team atmet auf. Doch eine Stunde später melden Nutzer, dass Seiten langsam laden. Einige Queries laufen ins Timeout. Ein paar API-Aufrufe geben 500-Fehler zurück. Die Migration war technisch erfolgreich, aber unter der Oberfläche ist etwas schiefgelaufen.

Dieses Szenario ist häufiger, als die meisten Teams erwarten. Eine Migration, die ohne Exception durchläuft, ist nicht dasselbe wie eine Migration, die das System in einem gesunden Zustand hinterlässt. Die Differenz zwischen diesen beiden Ergebnissen soll die Post-Migration-Verifikation aufdecken.

Warum Erfolgscodes nicht ausreichen

Die meisten Migrationstools geben einen Exit-Code von Null zurück, wenn sie fehlerfrei beendet werden. Das sagt Ihnen, dass das SQL ausgeführt und die interne Tracking-Tabelle aktualisiert wurde. Es sagt Ihnen nicht, ob das neue Schema gut mit der Anwendung zusammenarbeitet, ob sich die Query-Performance geändert hat oder ob die Migration Locks hinterlassen hat.

Eine Migration kann technisch erfolgreich sein und trotzdem echten Schaden anrichten. Das Hinzufügen einer Spalte mit einem Standardwert kann eine große Tabelle für Minuten sperren. Die Änderung eines Spaltentyps kann die Datenbank zwingen, Zeilen neu zu schreiben, was parallele Queries verlangsamt. Das Hinzufügen eines Index kann einer Query helfen, aber den Ausführungsplan für eine andere zerstören. Keines dieser Probleme zeigt sich im Exit-Code des Migrationstools.

Post-Migration-Verifikation ist die Praxis, den tatsächlichen Zustand der Datenbank und der Anwendung nach einer Migration zu überprüfen. Sie macht aus einem blinden Deployment ein informiertes.

Migrationsstatus richtig prüfen

Das Erste, was zu überprüfen ist, ist, ob die Migration tatsächlich vollständig durchgelaufen oder teilweise abgebrochen ist. Manche Tools wenden Migrationen in Batches an. Wenn eine Migration im dritten Batch fehlschlägt, haben die ersten beiden Batches die Datenbank bereits verändert. Der Exit-Code mag ungleich Null sein, aber der Schaden ist bereits teilweise eingetreten.

Sehen Sie sich die Tracking-Tabelle des Migrationstools oder dessen detaillierte Logs an. Finden Sie heraus, welche Anweisungen genau angewendet wurden und wo der Prozess gestoppt ist. Diese Information sagt Ihnen, ob die Datenbank in einem konsistenten Zustand ist oder ob eine manuelle Bereinigung vor einem erneuten Versuch nötig ist.

Verlassen Sie sich nicht allein auf den Exit-Code. Manche Migrationen erzeugen Warnungen, die nicht fatal sind, aber auf potenzielle Probleme hinweisen, wie veraltete Syntax oder implizite Typkonvertierungen. Protokollieren Sie diese Warnungen und nehmen Sie sie in den Pipeline-Bericht auf.

Query-Latenz vorher und nachher vergleichen

Schemaänderungen können beeinflussen, wie die Datenbank Queries ausführt. Eine Spalte, die zu einer Tabelle hinzugefügt wurde, kann den Query-Planner dazu bringen, einen anderen Index oder einen Full-Table-Scan zu wählen. Eine Datentypänderung kann die Indexnutzung für bestimmte Vergleiche deaktivieren.

Die Pipeline sollte vor und nach der Migration einen Satz repräsentativer Queries gegen die Datenbank ausführen. Vergleichen Sie die Latenz für jede Query. Wenn eine Query einen signifikanten Anstieg zeigt, ist das ein Signal, dass die Migration den Ausführungsplan auf eine Weise geändert hat, die die Performance beeinträchtigt.

Konzentrieren Sie sich auf die Queries, die die Anwendung am häufigsten verwendet oder die als performancekritisch bekannt sind. Führen Sie für diese Prüfung keine schweren analytischen Queries aus. Halten Sie die Verifikationsqueries leichtgewichtig, damit sie die Datenbank während des Deployment-Fensters nicht zusätzlich belasten.

Auf nicht freigegebene Locks prüfen

Migrationen, die das Schema ändern, müssen oft Locks auf Tabellen oder Zeilen erwerben. Die meisten Locks werden freigegeben, wenn die Migration beendet ist, aber nicht immer. Eine langlaufende Transaktion, eine nicht ordnungsgemäß geschlossene Verbindung oder eine Migration, die ein Timeout hatte, können Locks hinterlassen.

Nach Abschluss der Migration prüfen Sie die Datenbank auf aktive Locks. Wenn noch Locks gehalten werden, wird die Anwendung Timeouts oder Queue-Aufbau erleben, wenn sie auf die betroffenen Tabellen zugreift. Die Pipeline sollte auch protokollieren, wie lange Locks während der Migration gehalten wurden. Wenn ein Lock länger als ein paar Sekunden auf einer Produktionstabelle gehalten wurde, ist das eine Untersuchung wert, selbst wenn es schließlich freigegeben wurde.

Führen Sie diese Query aus, um zu sehen, ob noch Locks auf der migrierten Tabelle gehalten werden:

SELECT
    pg_locks.pid,
    pg_locks.mode,
    pg_locks.granted,
    pg_class.relname,
    pg_stat_activity.query,
    pg_stat_activity.state,
    pg_stat_activity.wait_event_type || ': ' || pg_stat_activity.wait_event AS wait
FROM pg_locks
JOIN pg_class ON pg_locks.relation = pg_class.oid
JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE pg_class.relname = 'your_table_name'
  AND pg_locks.granted = true;

Wenn Zeilen zurückgegeben werden, hat die Migration Locks hinterlassen. Untersuchen Sie die Spalten query und state, um zu verstehen, warum.

Zeilenanzahlen bei datenändernden Migrationen prüfen

Manche Migrationen ändern nicht nur das Schema. Sie befüllen neue Spalten mit Standardwerten, verschieben Daten zwischen Tabellen oder bereinigen Duplikate. Diese Operationen können stillschweigend Zeilen übersehen, wenn die Migrationslogik Randfälle hat oder wenn die Daten nicht dem erwarteten Format entsprechen.

Vergleichen Sie nach solchen Migrationen die tatsächliche Zeilenanzahl mit der erwarteten Zeilenanzahl. Wenn die Migration beispielsweise eine neue Spalte für alle vorhandenen Zeilen füllen sollte, prüfen Sie, ob die Anzahl der Zeilen mit einem Nicht-Null-Wert in dieser Spalte der Gesamtzeilenanzahl entspricht. Bei einer Abweichung wurde die Migration nicht auf alle Zeilen angewendet.

Führen Sie diese Prüfungen mit einfachen Count-Queries durch. Vermeiden Sie Joins oder Aggregationen, die unnötige Last auf die Datenbank bringen könnten.

Anwendungslogs auf Datenbankfehler überwachen

Der wichtigste Verifikationsschritt ist die Prüfung, ob die Anwendung nach der Migration noch mit der Datenbank zusammenarbeiten kann. Der aktuell laufende Anwendungscode wurde für das alte Schema geschrieben. Wenn die Migration das Schema so geändert hat, dass der laufende Code bricht, erscheinen Fehler in den Anwendungslogs.

Achten Sie auf Fehler, die fehlende Spalten, Typkonflikte oder fehlgeschlagene Queries erwähnen. Diese Fehler bedeuten, dass Anwendung und Datenbank nicht synchron sind. Das Team muss schnell entscheiden, ob die Migration zurückgerollt oder ein Code-Fix bereitgestellt werden soll, der zum neuen Schema passt.

Warten Sie nicht darauf, dass Nutzer diese Fehler melden. Die Pipeline sollte automatisch Anwendungslogs aus dem Monitoring-System abrufen und nach datenbankbezogenen Fehlern durchsuchen.

Eine praktische Post-Migration-Checkliste

Wenn Sie die Post-Migration-Verifikation zum ersten Mal einrichten, beginnen Sie mit diesen Prüfungen in Ihrer Pipeline:

Das folgende Flussdiagramm zeigt die empfohlene Reihenfolge der Verifikationsschritte:

flowchart TD A[Migration erfolgreich abgeschlossen] --> B[Migrationsstatus prüfen] B --> C[Query-Latenz vergleichen] C --> D[Auf Locks prüfen] D --> E[Zeilenanzahlen prüfen] E --> F[Anwendungslogs überwachen] F --> G{Alle Prüfungen bestanden?} G -- Ja --> H[Kann behalten werden] G -- Nein --> I[Team alarmieren]
  • Migrationsstatus: Ist sie vollständig durchgelaufen, und wo hat sie gestoppt, falls sie fehlschlug?
  • Query-Latenz: Liegen die Top-5-kritischen Queries noch im akzeptablen Bereich?
  • Locks: Gibt es nach der Migration noch aktive Locks?
  • Zeilenanzahlen: Entsprechen die Zahlen den Erwartungen bei datenändernden Migrationen?
  • Anwendungsfehler: Gibt es neue datenbankbezogene Fehler in den Logs?

Führen Sie diese Prüfungen automatisch nach jeder Migration durch. Senden Sie die Ergebnisse als Bericht an das Team. Wenn alle Prüfungen bestanden sind, ist die Migration sicher zu behalten. Wenn eine Prüfung fehlschlägt, hat das Team genügend Informationen, um den nächsten Schritt zu entscheiden.

Das Fazit

Ein grüner Migrationsstatus ist keine Garantie für Sicherheit. Der wahre Test ist, ob Datenbank und Anwendung nach der Änderung noch gut zusammenarbeiten. Post-Migration-Verifikation überbrückt die Lücke zwischen "die Migration lief" und "das System ist gesund". Ohne sie deployen Sie blind und hoffen auf das Beste.