Warum Datenbankmigrationen eine eigene Checkliste brauchen

Ein Entwickler pusht eine Änderung, die eine Spalte löscht. Die Deployment-Pipeline läuft grün. Die Anwendung wird erfolgreich deployed. Aber die Datenbankmigration wurde bereits ausgeführt, und die Spalte ist weg. Die alte Version der Anwendung, die noch auf diese Spalte verweist, kann nicht mehr starten. Das Team stellt fest, dass ein einfaches Zurücksetzen der Anwendung ohne Wiederherstellung der Datenbank nicht möglich ist. Und die Wiederherstellung der Datenbank bedeutet, alle Daten zu verlieren, die nach der Migration geschrieben wurden.

Dieses Szenario erleben Teams, die Datenbankänderungen genauso behandeln wie Code-Änderungen. Das Risikoprofil ist grundlegend anders. Wenn Anwendungscode bricht, kann man die vorherige Version erneut deployen. Wenn eine Datenbankmigration bricht, kann man das Geschehene nicht immer rückgängig machen. Daten können verloren gehen. Constraints können verletzt werden. Das Schema kann sich so verändert haben, dass ein einfaches Rollback ohne vollständige Wiederherstellung aus dem Backup unmöglich ist.

Deshalb brauchen Datenbankmigrationen ihre eigene Vorlage. Keine generische Deployment-Checkliste. Sondern etwas, das auf die Natur von Schemaänderungen, Datentransformationen und die irreversiblen Konsequenzen der Änderung von Produktionsdaten zugeschnitten ist.

Das Problem, Migrationen wie Code-Deployments zu behandeln

Code-Deployments sind relativ sicher, weil sie reversibel sind. Man deployed Version 2, sie hat einen Fehler, man deployed Version 1 erneut. Die Anwendung startet mit dem alten Code neu, und die Benutzer arbeiten weiter.

Datenbankmigrationen funktionieren so nicht. Sobald eine Migration läuft:

• Gelöschte Spalten können ohne eine Wiederherstellung nicht zurückgeholt werden
• Umbenannte Tabellen brechen Abfragen, die noch den alten Namen verwenden
• Datentransformationen, die Werte entfernen oder ändern, können nicht durch erneutes Ausführen der Migration rückgängig gemacht werden
• Die Erstellung oder Entfernung von Indizes kann die Abfrageleistung für Stunden oder Tage verändern

Das Risiko ist nicht nur technischer Natur. Es ist operativ. Eine fehlgeschlagene Migration kann die gesamte Anwendung lahmlegen, Tabellen für längere Zeit sperren und Koordination zwischen Entwicklern, DBAs und Betriebsteams zur Wiederherstellung erfordern.

Die Fünf-Schritte-Vorlage für Datenbankmigrationen

Eine gute Migrationsvorlage ist kein starres Skript. Es ist eine Abfolge von Prüfungen und Aktionen, die die Wahrscheinlichkeit von Überraschungen verringern. Jeder Schritt hat einen klaren Zweck, und das Überspringen eines Schrittes erhöht das Risiko.

Das folgende Flussdiagramm veranschaulicht die Fünf-Schritte-Vorlage und die wichtigsten Entscheidungspunkte:

Schritt 1: Backup vor allem anderen

Bevor eine Migration läuft, muss die Datenbank gesichert werden. Dies ist kein Compliance-Kästchen. Es ist das letzte Sicherheitsnetz, wenn alles andere versagt.

Das Backup muss für eine Wiederherstellung auf den genauen Zustand vor der Migration verwendbar sein. Das bedeutet:

Ein reversibles Migrationsskript kombiniert die Vorwärtsänderung mit einem Rollback und macht klar, wie man bei Bedarf rückgängig macht:

-- Up: Spalte mit Standardwert hinzufügen
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP DEFAULT NULL;

-- Down: Spalte entfernen (nur sicher, wenn kein Code davon abhängt)
ALTER TABLE users DROP COLUMN last_login_at;

• Die Backup-Datei muss auf Gültigkeit geprüft werden, nicht nur erstellt
• Die Wiederherstellungsprozedur muss dokumentiert und geübt sein
• Bei risikoreichen Migrationen ist ein manuelles Backup unmittelbar vor der Migration besser als die Abhängigkeit von automatischen täglichen Backups

Manche Teams haben jede Nacht automatische Backups. Das ist für den Routinebetrieb in Ordnung. Aber für eine Migration, die eine Tabelle löscht oder Millionen von Zeilen ändert, sollte man ein Backup direkt vor dem Start der Migration erstellen. Das Backup sollte an einem Ort gespeichert werden, der von der Migration selbst nicht betroffen ist.

Schritt 2: Dry-Run in einer realistischen Umgebung

Ein Dry-Run bedeutet, die Migration in einer Nicht-Produktionsumgebung auszuführen, die die Produktion so genau wie möglich abbildet. Ziel ist es, Probleme zu finden, bevor sie in der Produktion auftreten.

Das Schlüsselwort ist „realistisch". Die Migration auf einer Datenbank mit zehn Zeilen auszuführen, sagt nichts darüber aus, wie sie sich auf einer Datenbank mit zehn Millionen Zeilen verhält. Eine Migration, die auf einer leeren Datenbank in zwei Sekunden abgeschlossen ist, kann bei Produktionsdaten zwanzig Minuten dauern. Während dieser zwanzig Minuten können Tabellen gesperrt sein, Abfragen in Warteschlangen landen und die Anwendung nicht mehr reagieren.

Eine ordentliche Dry-Run-Umgebung sollte Folgendes haben:

• Schema identisch zur Produktion
• Datenvolumen nahe an der Produktion oder zumindest repräsentativ für die größten zu ändernden Tabellen
• Ähnliche Hardware- oder Ressourcenbeschränkungen, insbesondere für CPU und I/O

Führe die Migration aus. Notiere, wie lange jede Anweisung dauert. Achte auf Sperrkonflikte. Prüfe auf Fehler. Wenn der Dry-Run Probleme aufdeckt, behebe sie, bevor du die Produktion berührst.

Schritt 3: Migration in der Produktion ausführen

Dies ist der kritische Moment. Die Migration sollte während verkehrsarmer Zeiten laufen. Nicht, weil die Migration selbst fehlschlagen wird, sondern weil die Auswirkungen eines Problems geringer sind, wenn weniger Benutzer betroffen sind.

Während der Ausführung aktiv überwachen:

• Wie lange dauert jede Anweisung?
• Gibt es Sperren, die andere Abfragen blockieren?
• Bedient die Anwendung noch Anfragen, oder laufen Verbindungen zeitlich aus?
• Steigen die Fehlerraten in den Anwendungslogs?

Wenn die Migration länger dauert als erwartet, nimm nicht an, dass sie irgendwann fertig wird. Habe einen Plan zum Abbrechen oder Anhalten. Manche Migrationen können in kleinere Batches aufgeteilt werden. Andere erfordern möglicherweise, die Anwendung vorübergehend in den Wartungsmodus zu versetzen.

Schritt 4: Ergebnis verifizieren

Vertraue nicht auf einen grünen Exit-Code. Eine Migration kann ohne Fehler abgeschlossen sein und die Datenbank dennoch in einem defekten Zustand hinterlassen. Verifikation bedeutet, zu prüfen, ob das Schema den Erwartungen entspricht und die Anwendung sich verbinden und funktionieren kann.

Verifiziere durch:

• Prüfen, ob neue Spalten mit den korrekten Datentypen existieren
• Bestätigen, dass Datentransformationen die erwarteten Werte erzeugt haben
• Ausführen einer Testabfrage, die das geänderte Schema nutzt
• Verbinden der Anwendung mit der Datenbank und Prüfen auf Verbindungsfehler

Wenn die Migration Constraints hinzugefügt hat, verifiziere, dass vorhandene Daten diese erfüllen. Wenn die Migration Constraints entfernt hat, verifiziere, dass die Anwendung auch ohne sie korrekt funktioniert.

Schritt 5: Kurzfristige Auswirkungen überwachen

Schemaänderungen hören nicht auf, das System zu beeinflussen, sobald die Migration abgeschlossen ist. Sie können Ausführungspläne von Abfragen verändern, die Indexnutzung ändern und neue Sperrmuster einführen. Diese Effekte treten möglicherweise nicht sofort auf.

Überwache für die nächsten Stunden:

• Gibt es neue langsame Abfragen in der Datenbank?
• Sind die Fehlerraten in der Anwendung höher als zuvor?
• Gibt es Deadlocks, die es vorher nicht gab?
• Reagiert die Anwendung innerhalb normaler Latenzbereiche?

Nutze vorhandene Überwachungswerkzeuge. Verlasse dich nicht auf manuelle Log-Prüfungen. Richte Alarme für jede Verschlechterung ein, die mit dem Zeitpunkt der Migration korreliert.

Praktische Checkliste für Datenbankmigrationen

Das Fazit

Datenbankmigrationen sind keine Code-Deployments. Sie haben irreversible Konsequenzen, die einen anderen Ansatz erfordern. Eine Fünf-Schritte-Vorlage – Backup, Dry-Run, Ausführung, Verifikation, Überwachung – gibt deinem Team eine strukturierte Möglichkeit, Risiken zu reduzieren. Verwende sie für jede Migration, egal wie klein. Die Migration, die zu einfach erscheint, um eine Checkliste zu benötigen, ist oft die, die den meisten Schaden anrichtet.