Eine unterbrochene Migration ist nicht immer einfach nur „halb fertig“. Sie kann angehalten worden sein, bevor eine Einheit gespeichert wurde, nachdem einige Änderungen bestätigt wurden oder nachdem das Zielsystem mehrdeutig geantwortet hat. Auch kann der Prozess abgeschlossen sein und dennoch Abweichungen hinterlassen haben. Um zu entscheiden, wie es weitergeht, muss das Team anhand überprüfbarer Belege rekonstruieren, was geschehen ist, statt sich allein auf den Exit-Code oder die zuletzt protokollierte Kennung zu verlassen.
Die praktische Frage lautet nicht nur, wie sich eine fehlgeschlagene Datenmigration in PHP fortsetzen lässt, sondern auch, was sich über den Status jeder Einheit mit Sicherheit sagen lässt und welche Prüfungen erforderlich sind, bevor ein Vorgang wiederholt wird. Diese Unterscheidung verringert das Risiko von Duplikaten, fehlerhaften Beziehungen und manuellen Korrekturen, die sich nur schwer auditieren lassen.
Zuerst zwischen einem angehaltenen Lauf und einer Migration mit Abweichungen unterscheiden
Ein angehaltener Lauf ist ein Prozess, der nicht mehr fortgeschritten ist, etwa aufgrund einer Ausnahme, eines Verbindungsverlusts oder eines operativen Eingriffs. Eine Migration mit Abweichungen hingegen erfüllt die erwarteten Bedingungen nicht, obwohl der Prozess fehlerfrei beendet wurde. Es können Zeilen fehlen, Schlüssel falsch transformiert oder Beziehungen unvollständig sein.
Ein globaler Status wie abgeschlossen oder fehlgeschlagen reicht daher nicht aus. Mindestens sollte zwischen laufend, angehalten, abgeschlossen und mit Abweichungen abgeschlossen unterschieden werden. Der globale Status fasst die Arbeit zusammen, ersetzt aber weder das Protokoll je Einheit noch die Validierung des Ergebnisses.
Bevor Sie den Befehl erneut ausführen, sichern Sie die verfügbaren Protokolle und bestimmen Sie, welches System in dieser Phase die maßgebliche Datenquelle ist. Wenn nach der Migration Schreibvorgänge, manuelle Änderungen oder parallele Prozesse stattfinden, ermitteln Sie, wie diese den Vergleich beeinflussen. Ohne diese Informationen fortzufahren, kann eine untersuchbare Abweichung zu einem Verlust der Nachvollziehbarkeit führen.
Arbeitseinheiten und überprüfbare Kontrollpunkte festlegen
Wählen Sie eine Arbeitseinheit, die zu den Daten und zur Wiederherstellung passt: Das kann eine Entität, eine Gruppe zusammengehöriger Datensätze oder eine stabile Partition sein. Vermeiden Sie es, den Kontrollpunkt einfach als „zuletzt verarbeitete ID“ festzulegen. Diese ID belegt höchstens, dass das Programm eine bestimmte Position erreicht hat. Sie beweist weder, dass alle vorherigen Datensätze korrekt gespeichert wurden, noch, dass das Zielsystem konsistent ist.
Halten Sie für jede Einheit einen stabilen Quellschlüssel, die Version oder Kennung des Laufs, den Status und ein überprüfbares Ergebnis fest. Der Kontrollpunkt muss sich mit dem Zielsystem abgleichen lassen, zum Beispiel anhand eines Zielschlüssels, eines Fingerabdrucks relevanter Felder oder einer Prüfungsabfrage. Wenn sich die Daten während des Prozesses ändern können, protokollieren Sie außerdem das Auswahlkriterium oder den verwendeten Stichtag.
Das Design hängt von der Umgebung ab. Teilen sich Quelle und Ziel eine Transaktion, kann diese einen Nachweis für die gemeinsame Bestätigung liefern. Handelt es sich um unterschiedliche Systeme, dürfen Sie keine Atomarität zwischen ihnen voraussetzen. Bei einer Integration über eine API kann eine verlorene Antwort unklar lassen, ob der Server den Vorgang ausgeführt hat. Die Strategie muss dieser Unsicherheit Rechnung tragen und eine nachträgliche Prüfung ermöglichen, statt die Einheit automatisch als fehlgeschlagen oder bestätigt zu kennzeichnen.
Für jede Einheit protokollieren, was versucht und was bestätigt wurde
Ein für den Support nützliches Protokoll beantwortet, wer die Migration ausgeführt hat, welche Einheit bearbeitet wurde, wann sich ihr Status geändert hat und welche Belege vorliegen. Unterscheiden Sie zwischen verarbeitet – der Code hat Schritte ausgeführt – und bestätigt – es gibt ein zuverlässiges Signal dafür, dass das erwartete Ergebnis im Zielsystem vorhanden ist. Ergänzen Sie die Anzahl der Versuche, eine Fehlerkategorie und eine Korrelationskennung, mit der sich Prozessereignisse mit externen Aufrufen verknüpfen lassen.
Die Statuswerte sollten operative Situationen beschreiben und nicht nur Algorithmusphasen. Beispiele sind: ausstehend, in Bearbeitung, Bestätigung ungewiss, bestätigt und Überprüfung erforderlich. Beendet sich der Prozess, während eine Einheit als in Bearbeitung markiert ist, muss sie beim Neustart bis zur Prüfung des Zielsystems als ungewiss behandelt werden. Kennzeichnen Sie sie nicht als fehlgeschlagen, ohne zu überprüfen, ob sie bereits Auswirkungen hatte.
Protokollieren Sie genügend Informationen für eine Untersuchung, aber schreiben Sie keine Zugangsdaten, Geheimnisse oder unnötigen personenbezogenen Daten in Logs. Fehler sollten die Identifizierung der Einheit und des Vorgangs ermöglichen, ohne dass die Nachvollziehbarkeit die Datenexposition erhöht. Legen Sie außerdem fest, wer diese Protokolle einsehen und aufbewahren darf.
Invarianten vergleichen, bevor Sie über das weitere Vorgehen entscheiden
Invarianten sind Bedingungen, die unabhängig von der Implementierung der Migration erfüllt sein müssen. Zählungen nach Typ oder Partition helfen, Unterschiede zu finden, reichen aber nicht aus: Zwei Mengen können gleich groß sein und dennoch unterschiedliche Datensätze enthalten. Vergleichen Sie Geschäftsschlüssel, das Vorhandensein von Datensätzen, Beziehungen und relevante Regeln, etwa zulässige Statuswerte oder neu berechnete Beträge.
Wählen Sie Prüfungen, die dem Risiko und dem Datenvolumen angemessen sind. Eine Stichprobe kann der Diagnose dienen, beweist aber für sich genommen nicht, dass der gesamte Datenbestand korrekt ist. Für eine umfassende Validierung vergleichen Sie Schlüssel oder Fingerabdrücke blockweise und protokollieren Sie, welche Blöcke geprüft wurden. Wenn die Transformation Felder bewusst verändert, dokumentieren Sie, welche Unterschiede erwartet werden und welche auf einen Fehler hindeuten.
Wenn die Quelle weiterhin Änderungen erhält, trennen Sie Abweichungen aufgrund paralleler Änderungen von solchen, die durch die Migration verursacht wurden. Gegebenenfalls müssen Sie ein Zeitfenster festlegen, nachträgliche Änderungen erfassen oder eine Synchronisierungsphase wiederholen. Ohne eine klare Regel für parallele Änderungen kann der Vergleich zwischen Systemen falsche positive Ergebnisse liefern oder neue Daten übersehen.
Nur auf Grundlage von Belegen fortsetzen und ungewisse Ergebnisse berücksichtigen
Bei einer sicheren Fortsetzung werden ausstehende und bestätigte Einheiten geladen, Einheiten mit ungewissem Status aber nicht als gültig vorausgesetzt. Fragen Sie für diese Einheiten das Zielsystem anhand eines stabilen Schlüssels ab und vergleichen Sie das Ergebnis mit der erwarteten Transformation. Stimmt es überein, protokollieren Sie die Bestätigung, ohne die Wirkung zu wiederholen. Ist es nicht vorhanden, kann ein erneuter Versuch angemessen sein. Ist es mit abweichendem Inhalt vorhanden, halten Sie die Bearbeitung dieser Einheit an und untersuchen Sie den Fall.
Wenn die Wiederholung eines Vorgangs Duplikate oder externe Auswirkungen verursachen kann – etwa den Versand einer Benachrichtigung –, verwenden Sie einen idempotenten Vorgang oder einen Idempotenzschlüssel, sofern das beteiligte System dies unterstützt. Ist das nicht möglich, entwerfen Sie eine Vorabprüfung und einen Abgleichsprozess. Gehen Sie nicht davon aus, dass eine Ausnahme bedeutet, es sei nichts geschrieben worden: Der Fehler kann aufgetreten sein, nachdem die Änderung bestätigt wurde, aber bevor die Antwort einging.
Prüfen Sie vor der Fortsetzung, ob dasselbe Mapping, dieselbe Schlüsselrichtlinie und die korrekte Version des Codes oder der Konfiguration verwendet werden. Ein Kontrollpunkt, der mit einer anderen Transformation erzeugt wurde, kann irreführend sein. In PHP sollte der Migrationsbefehl einen eindeutig identifizierbaren Lauf unterstützen und strukturierte Statusmeldungen ausgeben. So kann eine Person das Protokoll mit den Daten abgleichen, statt sich auf allgemeine Konsolenmeldungen zu verlassen.
Abbruchbedingungen festlegen und mit einem Bericht abschließen
Halten Sie die Fortsetzung an, wenn Schlüsselkonflikte auftreten, ungültige Daten eine Geschäftsregel erfordern, verwaiste Beziehungen vorliegen, ungewisse Ergebnisse nicht überprüft werden können oder Abweichungen die akzeptierten Grenzwerte überschreiten. Halten Sie sie auch an, wenn sich anhand der verfügbaren Belege nicht feststellen lässt, was geschehen ist. In solchen Fällen ist es meist sicherer, den Fall zu eskalieren und den Zustand zu bewahren, als blind einen neuen Versuch zu starten.
Führen Sie nach Abschluss die globalen Prüfungen durch: bestätigte gegenüber erwarteten Einheiten, Zählungen und Schlüssel, Beziehungen sowie die für die Migration festgelegten Geschäftsregeln. Erstellen Sie einen Bericht, der angibt, was migriert und überprüft wurde, was erneut versucht wurde und welche Abweichungen noch offen sind, und fügen Sie Verweise hinzu, die eine Untersuchung ermöglichen. Erklären Sie die Arbeit nicht allein deshalb für abgeschlossen, weil der Prozess mit Exit-Code null beendet wurde.
Das Kriterium für die Fortsetzung lässt sich einfach formulieren, erfordert aber technische Disziplin: Jede Einheit muss bestätigt, als nicht angewendet verifiziert oder zur Überprüfung zurückgestellt werden. Dieser explizite Status ermöglicht zusammen mit vergleichbaren Invarianten und aussagekräftigen Protokollen, eine PHP-Migration fortzusetzen, ohne Fortschritt mit Erfolg oder Unsicherheit mit einer Erlaubnis zur Wiederholung zu verwechseln.
