Wenn die Datenmigration schiefgeht: Rollback-Strategien, die wirklich funktionieren

Sie haben gerade eine Datenbankmigration in Produktion deployed. Das Skript lief zwölf Minuten, änderte drei Tabellen, verschob Daten zwischen Spalten – und scheiterte dann an der letzten Anweisung. Die Hälfte der Änderungen ist angewendet, die andere nicht. Ihre Anwendung liefert jetzt Fehler, weil sie ein Schema erwartet, das nicht vollständig existiert.

In diesem Moment stellen die meisten Teams fest, dass ein Rollback einer Datenmigration nichts mit dem Zurückrollen eines Application-Deployments zu tun hat. Bei Anwendungscode tauschen Sie das Binary oder das Container-Image aus, und die alte Version läuft wieder. Bei Daten können Sie das Löschen einer Spalte nicht durch erneutes Deployen des alten Codes rückgängig machen. Die Spalte ist weg. Die darin enthaltenen Daten sind möglicherweise auch weg.

Eine Rollback-Strategie für Datenmigrationen muss existieren, bevor die Migration startet. Sie erst nach dem Fehler zu planen, ist zu spät.

Backup vor der Migration, nicht danach

Der mit Abstand zuverlässigste Rollback-Mechanismus ist ein vollständiger Snapshot der Datenbank, der unmittelbar vor Beginn der Migration erstellt wird. Das ist nicht Ihr nächtliches Backup. Es ist eine Point-in-Time-Kopie, die den exakten Zustand der Daten direkt vor der Änderung festhält.

Dieses Backup sollte als Teil der Pipeline automatisiert werden. Bevor der Migrationsschritt läuft, löst die Pipeline einen Datenbank-Dump, einen Snapshot oder einen Replikations-Stopp aus, der einen Wiederherstellungspunkt erzeugt. Wenn der Backup-Schritt fehlschlägt, stoppt die Pipeline. Die Migration wird nicht ausgeführt. Das eliminiert den menschlichen Fehler, vor dem Deployment ein manuelles Backup zu vergessen.

Das folgende Flussdiagramm zeigt den Entscheidungsweg nach einem Migrationsfehler und hilft Ihnen, die passende Rollback-Methode für die Situation zu wählen.

flowchart TD A[Pre-Migration Backup Created] --> B[Migration Runs] B --> C{Migration Succeeded?} C -->|Yes| D[Done] C -->|No| E{Choose Rollback Method} E -->|Destructive change or data loss| F[Point-in-Time Recovery] E -->|Reversible schema change| G[Version Rollback - Down Migration] E -->|Full snapshot available| H[Restore Pre-Migration Snapshot] F --> I[Investigate Root Cause] G --> I H --> I I --> J[Fix Migration Script] J --> B

Für Cloud-Datenbanken bedeutet das oft, einen Snapshot des Volumes zu erstellen oder einen Klon der Instanz anzulegen. Bei selbst gehosteten Datenbanken bedeutet es, einen Dump-Befehl auszuführen oder Dateisystem-Snapshots zu verwenden. Wichtig ist, dass das Backup verifizierbar ist. Eine Backup-Datei, die nicht wiederhergestellt werden kann, ist kein Backup.

Migrations-Version-Rollback hat Grenzen

Die meisten Migrations-Frameworks unterstützen Vorwärts- und Rückwärts-Versionen. Flyway nennt sie migrate und undo. Liquibase nennt sie update und rollback. Alembic nennt sie upgrade und downgrade. Diese Tools können Schema-Änderungen rückgängig machen, indem sie ein Down-Migrationsskript ausführen.

Der Haken ist, dass Down-Migrationen nur bei reversiblen Änderungen sicher funktionieren. Das Hinzufügen einer nullable Spalte ist reversibel: Die Down-Migration löscht die Spalte, und es gehen keine Daten verloren. Das Umbenennen einer Spalte ist reversibel, wenn die Down-Migration sie zurückbenennt. Aber destruktive Änderungen sind eine andere Geschichte. Wenn Sie eine Spalte löschen, kann die Down-Migration sie zwar neu erstellen, aber die Daten, die in dieser Spalte waren, sind weg. Wenn Sie Daten von einem Format in ein anderes transformieren, kann die Down-Migration die Transformation nur rückgängig machen, wenn Sie die ursprünglichen Werte irgendwo gespeichert haben.

Version-Rollback ist nützlich, um Fehler frühzeitig zu erkennen, z. B. eine Migration, die in der falschen Umgebung deployed wurde, oder eine Schema-Änderung, die eine Query zerstört. Aber es ist kein Sicherheitsnetz gegen Datenverlust. Sich ausschließlich auf Down-Migrationen zu verlassen, ist ein häufiger Fehler, der beim Rollback zu Datenverlust führt.

Point-in-Time Recovery als Sicherheitsnetz

Die robusteste Rollback-Strategie hängt überhaupt nicht von Migrationsskripten ab. Point-in-Time Recovery nutzt das Transaktionslog der Datenbank, um die Datenbank auf einen beliebigen Zeitpunkt vor dem Start der Migration zurückzusetzen.

So funktioniert es. Die Datenbank schreibt kontinuierlich Transaktionslogs oder Write-Ahead-Logs, die jede Änderung aufzeichnen. Wenn Sie diese Logs und ein Basis-Backup haben, können Sie die Logs bis zu einem bestimmten Zeitstempel abspielen. Wenn eine Migration um 14:00 Uhr fehlschlägt, stellen Sie die Datenbank auf 13:59 Uhr wieder her, bevor die Migration begann. Alle Änderungen durch die Migration sind verschwunden, und die Datenbank ist in ihrem ursprünglichen Zustand, unabhängig davon, wie destruktiv die Migration war.

Point-in-Time Recovery erfordert Vorbereitung. Die Datenbank muss so konfiguriert sein, dass Transaktionslogs kontinuierlich archiviert werden. Das Team muss über die Tools und Berechtigungen verfügen, um eine Wiederherstellung zu einem bestimmten Zeitpunkt durchzuführen. Und der Prozess muss regelmäßig getestet werden. Viele Teams stellen fest, dass ihr Point-in-Time-Recovery-Setup defekt ist, erst dann, wenn sie es während eines Incidents brauchen.

Dieser Ansatz funktioniert für jede Migration, auch für destruktive. Es spielt keine Rolle, ob die Migration Spalten hinzugefügt, Tabellen gelöscht oder Millionen von Zeilen transformiert hat. Es spult einfach die Zeit zurück.

Testen Sie das Rollback, nicht nur die Migration

Eine Migration, die alle Tests in der Staging-Umgebung besteht, kann in Produktion dennoch fehlschlagen – aufgrund unerwarteter Datenmengen, Locking-Konflikten oder Edge Cases in den Daten. Gleiches gilt für das Rollback. Der einzige Weg, um zu wissen, dass ein Rollback funktioniert, ist, es zu testen.

Führen Sie die Migration in Ihrer Staging-Umgebung durch. Versuchen Sie dann, mit jeder Ihrer Strategien zurückzurollen: der Down-Migration, dem Pre-Migration-Backup und Point-in-Time Recovery. Messen Sie, wie lange jede Methode dauert. Wenn Point-in-Time Recovery vier Stunden dauert, ist das eine wichtige Information, bevor ein Produktionsincident eintritt.

Wenn das Rollback fehlschlägt oder zu lange dauert, beheben Sie den Prozess, bevor Sie ihn brauchen. Dieses Testen sollte Teil Ihrer Pipeline sein. Ein geplanter Job kann wöchentlich einen Migrations- und Rollback-Zyklus in Staging durchführen, um zu überprüfen, ob die Wiederherstellungsmechanismen nach Infrastrukturänderungen noch funktionieren.

Nach dem Rollback: Untersuchen, bevor Sie es erneut versuchen

Wenn ein Rollback erfolgreich ist, ist die natürliche Reaktion, das Migrationsskript zu korrigieren und erneut auszuführen. Widerstehen Sie diesem Impuls. Der Fehler könnte ein tieferes Problem offenbart haben: eine Dateninkonsistenz, die die Migration nicht berücksichtigt hat, eine Race Condition mit einem anderen Prozess oder ein Missverständnis des Schemas.

Untersuchen Sie zuerst die Ursache. Prüfen Sie die Migrationslogs. Sehen Sie sich die Daten an, die den Fehler verursacht haben. Überprüfen Sie, ob die Migration von einer Datenform ausgegangen ist, die in Produktion nicht existiert. Erst wenn Sie verstehen, warum es fehlgeschlagen ist, sollten Sie das Skript ändern und es erneut versuchen.

Praxis-Checkliste für das Migrations-Rollback

  • Automatisieren Sie einen Pre-Migration-Backup-Schritt in der Pipeline. Wenn das Backup fehlschlägt, schlägt die Pipeline fehl.
  • Schreiben Sie Down-Migrationen nur für reversible Schema-Änderungen. Verlassen Sie sich bei destruktiven Operationen nicht auf sie.
  • Konfigurieren Sie Point-in-Time Recovery für Ihre Datenbank und testen Sie es mindestens einmal pro Quartal.
  • Testen Sie das Rollback in Staging vor jeder Produktionsmigration, nicht nur während der Ersteinrichtung.
  • Dokumentieren Sie die Rollback-Prozedur und die geschätzte Wiederherstellungszeit für jede Umgebung.
  • Untersuchen Sie nach einem Rollback die Ursache, bevor Sie die Migration erneut versuchen.

Die konkrete Erkenntnis

Ein Datenmigrations-Rollback ist kein Skript, das Sie ausführen. Es ist ein System, das Sie bauen, bevor die Migration startet. Das Pre-Migration-Backup ist Ihre erste Verteidigungslinie. Point-in-Time Recovery ist Ihr letzter Ausweg. Down-Migrationen sind nur für die engen Fälle nützlich, in denen Änderungen reversibel sind. Testen Sie alle in Staging, dokumentieren Sie die Prozedur und gehen Sie niemals davon aus, dass ein Rollback funktioniert, bis Sie es bewiesen haben.