Eine Migration kann Millionen von Datensätzen verändern, aktive Prozesse versorgen und Auswirkungen außerhalb der Datenbank erzeugen. Schlägt eine Transformation auf halbem Weg fehl, ist es nicht immer sicher oder akzeptabel, eine vollständige Sicherung wiederherzustellen: Möglicherweise wurden nach der Sicherung neue Daten geschrieben, oder das System kann nicht so lange angehalten werden, wie die Wiederherstellung dauert.
Ein Rollback-Plan für Datenmigrationen darf sich deshalb nicht auf einen Befehl zum Rückgängigmachen beschränken. Er muss festlegen, wie der betroffene Zustand ermittelt wird, welche Vorgänge rückgängig gemacht werden können, welche eine Kompensation erfordern und wann eine Reparatur oder Fortsetzung sinnvoll ist. Die Entscheidung wird vor der Ausführung der Migration vorbereitet – anhand von Kriterien, die das Team auch unter Druck überprüfen kann.
Warum das Wiederherstellen einer Sicherung nicht immer eine praktikable Rückgängigmachung ist
Eine Sicherung dient dazu, Daten nach bestimmten Vorfällen wiederherzustellen. Ihre Wiederherstellung kann jedoch legitime Änderungen löschen, die nach ihrer Erstellung vorgenommen wurden. Sie kann außerdem Ausfallzeiten, eine Neuerstellung von Indizes oder den Verlust von Schreibvorgängen zur Folge haben, die andere Systeme bereits erreicht haben. Bei Replikation, Warteschlangen, Exporten oder Integrationen macht die Wiederherstellung einer Datenbank diese Auswirkungen nicht automatisch rückgängig.
Es gilt, drei Maßnahmen zu unterscheiden. Wiederherstellen bedeutet, eine Sicherung einzuspielen oder einen Zustand zu einem früheren Zeitpunkt wiederherzustellen; rückgängig machen bedeutet, die Änderungen der Migration aufzuheben; kompensieren bedeutet, neue Vorgänge anzuwenden, die ihre Auswirkungen korrigieren. Diese Maßnahmen sind nicht gleichbedeutend: Eine Kompensation kann einen anderen Verlauf als den ursprünglichen hinterlassen, auch wenn sie die Geschäftsregeln wiederherstellt.
Die Wahl hängt vom Ausmaß des Fehlers, den nachfolgenden Schreibvorgängen und den Wiederherstellungszielen ab. Legen Sie vor Beginn fest, welcher Datenverlust tolerierbar ist, wie lange eine Unterbrechung dauern darf und wer eine Wiederherstellung genehmigt. Sind diese Grenzen nicht definiert, fehlt dem Team eine operative Entscheidungsgrundlage.
Jede Transformation nach ihrer Wiederherstellbarkeit klassifizieren
Beschreiben Sie jeden Migrationsschritt und ordnen Sie ihn dem vorgesehenen Wiederherstellungsverfahren zu:
- Rückgängig zu machen: Es gibt einen zuverlässigen inversen Vorgang. Beispielsweise wird der ursprüngliche Wert vor der Normalisierung eines Feldes gespeichert und kann wiederhergestellt werden, ohne spätere Änderungen zu überschreiben.
- Kompensierbar: Der vorherige Zustand lässt sich nicht exakt rekonstruieren, aber ein neuer Vorgang kann die Auswirkung anhand einer Geschäftsregel korrigieren. Die Kompensation muss ausdrücklich festgelegt, auditierbar und nach Möglichkeit idempotent sein.
- Irreversibel: Informationen werden verworfen oder es tritt eine Wirkung ein, die sich nicht zuverlässig rückgängig machen lässt. Dafür braucht es eine ausdrückliche Entscheidung zur Risikoakzeptanz, zur Aufbewahrung der Quelldaten und zu zusätzlichen Prüfungen.
Die Einstufung sollte nicht allein anhand der Art der SQL-Anweisung erfolgen. Eine Massenaktualisierung kann rückgängig zu machen sein, wenn der vorherige Wert gespeichert und die Nebenläufigkeit kontrolliert wird. Sie kann es hingegen nicht sein, wenn andere Prozesse während der Ausführung dieselben Zeilen ändern. Berücksichtigen Sie auch Nebenwirkungen wie Benachrichtigungen, API-Aufrufe, Abbuchungen oder Nachrichten in Warteschlangen. Häufig ist es besser, diese Aktionen von der Datentransformation zu trennen.
Ausgangszustand und Invarianten festlegen
Dokumentieren Sie vor der Ausführung den Umfang der Migration: einbezogene Entitäten, Filter, Anwendungsversion und angewandte Regeln. Definieren Sie eine Ausgangsbasis mit relevanten Zählwerten und, sofern sinnvoll, Aggregaten oder Prüfsummen stabiler Datensätze. Halten Sie den Referenzzeitpunkt und die Quelle dieser Daten fest. Ein Zahlenwert ohne Umfang und Kontext ermöglicht keine Überprüfung der Wiederherstellung.
Invarianten sind Bedingungen, die während und nach der Migration weiterhin gelten müssen. Dazu können Beziehungen zwischen Tabellen, Eindeutigkeit, zulässige Statuswerte, zu erhaltende Beträge oder die Übereinstimmung zwischen Datenbankdatensätzen und verbundenen Systemen gehören. Legen Sie für jede Invariante eine reproduzierbare Abfrage oder ein Verfahren sowie einen Akzeptanzschwellwert fest. Wenn sich die Daten während der Ausführung legitimerweise ändern, definieren Sie, wie sich diese Aktivität von den Auswirkungen der Migration unterscheiden lässt.
In einer PHP-Anwendung können Transformationen in Konsolenbefehlen oder Worker-Prozessen implementiert werden, statt sich auf eine lange Webanfrage zu stützen. Dadurch entfallen weder Nebenläufigkeitsrisiken noch Transaktionsgrenzen: Legen Sie fest, welche Einheit atomar ausgeführt werden kann und was zu tun ist, wenn der Prozess zwischen zwei Vorgängen endet.
Batches, Checkpoints und eine fortsetzbare Ausführung entwerfen
Teilen Sie die Arbeit in Batches mit klar definierten Grenzen auf, etwa anhand eines stabilen, sortierten Schlüssels. Vermeiden Sie Offset-Paginierung, wenn sich Zeilen während des Prozesses ändern oder verschwinden können; ein Fortsetzungsmarker auf Basis eines Schlüssels ist meist besser vorhersehbar. Die Batchgröße sollte die Dauer der Transaktionen, die Belastung der Datenbank und die Möglichkeit, Fehler zu erkennen, gegeneinander abwägen.
Speichern Sie nach jedem Batch einen Checkpoint mit der Job-ID, dem verarbeiteten Bereich, dem Status, dem Zeitstempel und den Validierungsergebnissen. Die Aktualisierung der Daten und das Vorrücken des Checkpoints müssen aufeinander abgestimmt sein, damit kein Batch als verarbeitet gilt, bevor er bestätigt wurde. Können beide Vorgänge nicht Teil derselben Transaktion sein, entwickeln Sie ein Abgleichverfahren, das den Zwischenzustand erkennt.
Bei einer fortsetzbaren Migration werden Änderungen nicht blind erneut angewendet. Jeder Vorgang muss Wiederholungen tolerieren oder prüfen, ob die Wirkung bereits eingetreten ist. In PHP lässt sich das je nach Datenbank-Engine und Datenmodell durch Transaktionen, Eindeutigkeitsbedingungen und idempotente Vorgänge unterstützen. Testen Sie auch gezielte Unterbrechungen: Ein Deployment, eine Exception oder ein Verbindungsabbruch sollte die Arbeit nicht in einem Zustand zurücklassen, für den es keinen bekannten Fortsetzungsweg gibt.
Änderungen protokollieren, um Auswirkungen zu ermitteln und Entscheidungen zu auditieren
Weisen Sie jeder Ausführung eine eindeutige ID zu und protokollieren Sie mindestens die Transformation, den Umfang, die Batches, die betroffenen Zeilen, die Fehler und die Entscheidungen zur Wiederherstellung. Bewahren Sie bei Änderungen, die kompensiert werden können, die erforderlichen vorherigen Daten oder einen sicheren Verweis darauf auf. Protokollieren Sie sensible Informationen nicht wahllos; beschränken Sie Zugriff, Aufbewahrungsdauer und Inhalt auf das, was für Wiederherstellung und Audit erforderlich ist.
Das Protokoll muss konkrete Fragen beantworten können: Welche Zeilen wurden verarbeitet? Welche Änderungen wurden bestätigt, welche schlugen fehl und welcher spätere Vorgang hat sie verändert? Ergänzen Sie technische Logs bei Bedarf durch eine Historie geschäftlicher Änderungen. Verwechseln Sie Nachvollziehbarkeit nicht mit einer Sicherung: Das Protokoll muss für seinen Zweck ausreichend detailliert sein und vor Verlust oder Veränderung geschützt werden.
Zwischen Fortsetzen, Kompensieren und Wiederherstellen wählen
Legen Sie Signale und Reaktionen im Voraus fest, statt bei einem Fehler ausschließlich nach Bauchgefühl zu entscheiden:
- Fortsetzen: wenn der Fehler vorübergehend ist, die Invarianten weiterhin gelten und die bestätigten Batches bekannt sind. Wiederholen Sie den Vorgang in begrenztem Umfang und beobachten Sie Fehler sowie Auslastung.
- Kompensieren: wenn die angewandten Änderungen bekannt sind und ein getesteter Korrekturvorgang existiert. Stoppen Sie zuerst neue, inkompatible Schreibvorgänge und stellen Sie sicher, dass die Kompensation keine gültigen Änderungen überschreibt.
- Wiederherstellen: wenn die Beschädigung weitreichend ist, die Wiederherstellung aus einer Sicherung validiert wurde und die Auswirkungen des Verlusts oder der Rekonstruktion späterer Änderungen akzeptabel sind. Stimmen Sie die Wiederherstellung mit Replikaten und Integrationen ab.
- Anhalten und eskalieren: wenn sich der Zustand nicht ermitteln lässt, Zählwerte unerklärlich voneinander abweichen oder die Kompensation weiteren Schaden verursachen könnte. Sichern Sie Belege, bevor Sie eingreifen.
Legen Sie Schwellenwerte fest, bei deren Überschreitung die Arbeit pausiert wird, etwa eine unzulässige Fehlerquote, eine verletzte Invariante oder eine Abweichung bei den Zählwerten. Bestimmen Sie, wer die Fortsetzung genehmigen und wer über eine Wiederherstellung entscheiden darf. Manchmal ist es am sichersten, den betroffenen Datenfluss zu isolieren und das System während der Untersuchung in einem kontrollierten Zustand zu halten.
Die Migration anhand einer Checkliste validieren und abschließen
Der Abschluss des Prozesses beweist nicht, dass die Daten korrekt sind. Vergleichen Sie Zählwerte vor und nach der Migration mit dem erwarteten Umfang, führen Sie Geschäftsregeln aus und prüfen Sie Beziehungen sowie Extremwerte. Verwenden Sie Stichproben, um einzelne Fälle zu untersuchen, aber nicht als Ersatz für vollständige Prüfungen, wenn diese möglich sind. Gibt es externe Verbraucher, überprüfen Sie auch deren Zustände und vereinbaren Sie, wie Abweichungen abgeglichen werden.
Vor der Ausführung: Klassifizieren Sie die Transformationen, bestätigen Sie Sicherung und Wiederherstellung, testen Sie Batches und Wiederholungen mit repräsentativen Daten und legen Sie Invarianten, Abbruchgrenzen, Verantwortliche und das Betriebsfenster fest. Stellen Sie sicher, dass das Team das Änderungsprotokoll einsehen kann und die Kompensations- oder Wiederherstellungsverfahren getestet wurden.
Nach der Ausführung: Validieren Sie Zählwerte und Regeln, überprüfen Sie Fehler und externe Auswirkungen, bewahren Sie das Ausführungsprotokoll auf und dokumentieren Sie alle Ausnahmen. Halten Sie die Wiederherstellungsinformationen für den vereinbarten Zeitraum verfügbar und löschen Sie sie sicher, sobald sie nicht mehr benötigt werden. Die Migration ist erst abgeschlossen, wenn die Ergebnisse überprüfbar sind und ausdrücklich entschieden wurde, wie mit offenen Abweichungen umzugehen ist.
