Een onderbroken migratie is niet altijd simpelweg ‘halverwege’. Het proces kan zijn gestopt voordat een eenheid werd opgeslagen, nadat enkele wijzigingen waren bevestigd of nadat de bestemming onduidelijk had gereageerd. Het proces kan ook zijn voltooid en toch afwijkingen hebben achtergelaten. Om te bepalen hoe het werk moet worden voortgezet, moet het team met verifieerbaar bewijs reconstrueren wat er is gebeurd, en niet alleen vertrouwen op de exitcode of de laatst geregistreerde identificatie.
De praktische vraag is niet alleen hoe je een mislukte datamigratie in PHP hervat, maar ook wat er over de status van elke eenheid kan worden vastgesteld en welke controles nodig zijn voordat een bewerking wordt herhaald. Dat onderscheid verkleint het risico op duplicaten, verbroken relaties en handmatige correcties die moeilijk te auditen zijn.
Maak eerst onderscheid tussen een gestopte uitvoering en een migratie met afwijkingen
Een gestopte uitvoering is een uitvoering waarvan het proces niet verderging, bijvoorbeeld door een exception, verbindingsverlies of operationele interventie. Een migratie met afwijkingen is daarentegen een migratie waarvan het resultaat niet aan de verwachte voorwaarden voldoet, ook al is het proces zonder fouten beëindigd. Er kunnen rijen ontbreken, sleutels onjuist zijn getransformeerd of relaties onvolledig zijn.
Daarom is een globale status zoals voltooid of mislukt onvoldoende. Maak ten minste onderscheid tussen een lopende, een gestopte en een voltooide uitvoering, en een uitvoering die met afwijkingen is voltooid. De globale status vat het werk samen, maar vervangt noch het logboek per eenheid, noch de validatie van het resultaat.
Bewaar de beschikbare logboeken voordat je de opdracht opnieuw uitvoert en bepaal welk systeem in deze fase de bron van waarheid is. Zijn er na de migratie schrijfbewerkingen, handmatige wijzigingen of gelijktijdige processen geweest, stel dan vast hoe die de vergelijking beïnvloeden. Zonder die informatie verdergaan kan een onderzoekbare afwijking veranderen in verlies van traceerbaarheid.
Definieer werkeenheden en verifieerbare controlepunten
Kies een werkeenheid die logisch is voor de gegevens en het herstel: dat kan een entiteit zijn, een groep gerelateerde records of een stabiele partitie. Gebruik niet simpelweg ‘de laatst verwerkte ID’ als controlepunt. Die ID toont hooguit aan dat het programma een bepaalde positie heeft bereikt; ze bewijst niet dat alle eerdere records correct zijn opgeslagen of dat de bestemming consistent is.
Bewaar voor elke eenheid een stabiele bronsleutel, de versie of identificatie van de uitvoering, de status en een verifieerbaar resultaat. Het controlepunt moet met de bestemming kunnen worden vergeleken, bijvoorbeeld aan de hand van een bestemmingssleutel, een hash op basis van relevante velden of een verificatiequery. Als de gegevens tijdens het proces kunnen veranderen, leg dan ook het selectiecriterium of het toegepaste peilmoment vast.
Het ontwerp hangt af van de omgeving. Als bron en bestemming één transactie delen, kan die bewijs leveren van een gezamenlijke bevestiging; als het verschillende systemen zijn, mag je geen atomiciteit tussen beide veronderstellen. Bij een integratie via een API kan een verloren antwoord onzekerheid veroorzaken over de vraag of de server de bewerking heeft toegepast. De strategie moet rekening houden met die onzekerheid en verificatie achteraf mogelijk maken, in plaats van de eenheid automatisch als mislukt of bevestigd te markeren.
Leg per eenheid vast wat is geprobeerd en wat is bevestigd
Een bruikbaar logboek voor support maakt het mogelijk te achterhalen wie de migratie heeft uitgevoerd, welke eenheid is verwerkt, wanneer de status is gewijzigd en met welk bewijs. Maak onderscheid tussen verwerkt — de code heeft stappen uitgevoerd — en bevestigd — er is een betrouwbaar signaal dat het verwachte resultaat in de bestemming bestaat. Voeg het pogingsnummer, een foutcategorie en een correlatie-ID toe om procesgebeurtenissen aan externe aanroepen te koppelen.
Statussen moeten operationele situaties beschrijven, niet alleen stappen in het algoritme. Denk bijvoorbeeld aan: openstaand, in uitvoering, bevestiging onzeker, bevestigd en controle vereist. Als het proces stopt terwijl een eenheid de status in uitvoering heeft, moet die na het herstarten als onzeker worden behandeld totdat de bestemming is geverifieerd. Markeer de eenheid niet als mislukt zonder te controleren of er effecten zijn opgetreden.
Leg voldoende informatie vast om onderzoek mogelijk te maken, maar schrijf geen inloggegevens, geheimen of onnodige persoonsgegevens naar logboeken. Fouten moeten de eenheid en de bewerking herkenbaar maken, zonder dat traceerbaarheid de blootstelling van gegevens vergroot. Bepaal ook wie deze logboeken mag raadplegen en bewaren.
Vergelijk invarianten voordat je bepaalt hoe je verdergaat
Invarianten zijn voorwaarden waaraan moet worden voldaan, ongeacht hoe de migratie is geïmplementeerd. Aantallen per type of partitie helpen verschillen te vinden, maar zijn niet voldoende: twee sets kunnen even groot zijn en toch verschillende records bevatten. Vergelijk business keys, de aanwezigheid van records, relaties en relevante regels, zoals toegestane statussen of opnieuw berekende bedragen.
Kies controles die passen bij de impact en het volume. Een steekproef kan als diagnose dienen, maar bewijst op zichzelf niet dat de volledige dataset correct is. Vergelijk voor een volledige validatie sleutels of hashwaarden per blok en leg vast welke blokken zijn gecontroleerd. Als de transformatie velden bewust wijzigt, documenteer dan welke verschillen verwacht zijn en welke op een fout wijzen.
Als er nog wijzigingen in de bron binnenkomen, maak dan onderscheid tussen afwijkingen door gelijktijdige wijzigingen en afwijkingen die door de migratie zijn veroorzaakt. Mogelijk moet je een peilmoment vastleggen, latere wijzigingen opvangen of een synchronisatiefase herhalen. Zonder een duidelijke regel voor gelijktijdige wijzigingen kan de vergelijking tussen systemen fout-positieven opleveren of nieuwe gegevens over het hoofd zien.
Hervat alleen op basis van bewijs en behandel onzekere resultaten zorgvuldig
Bij een veilige hervatting worden de openstaande en bevestigde eenheden geladen, maar worden eenheden met een onzekere status niet als geldig beschouwd. Raadpleeg voor die laatste groep de bestemming aan de hand van een stabiele sleutel en vergelijk het resultaat met de verwachte transformatie. Komt het overeen, registreer dan de bevestiging zonder het effect te herhalen; bestaat het niet, dan kan een nieuwe poging passend zijn. Bestaat het wel maar met andere inhoud, stop dan de verwerking van die eenheid en onderzoek de oorzaak.
Gebruik een idempotente bewerking of een idempotentiesleutel als het betrokken systeem die ondersteunt wanneer het herhalen van een bewerking duplicaten of externe effecten kan veroorzaken, zoals het versturen van een melding. Is dat niet mogelijk, ontwerp dan een controle vooraf en een procedure om de gegevens met elkaar in overeenstemming te brengen. Ga er niet van uit dat een exception betekent dat er niets is weggeschreven: de fout kan zijn opgetreden nadat de wijziging was bevestigd, maar voordat het antwoord werd ontvangen.
Controleer vóór hervatting of dezelfde mapping en hetzelfde sleutelbeleid worden gebruikt, en of de juiste versie van de code of configuratie actief is. Een controlepunt dat met een andere transformatie is gegenereerd, kan misleidend zijn. In PHP moet de migratieopdracht een herkenbare uitvoering accepteren en gestructureerde statussen uitsturen; zo kan iemand het logboek met de gegevens vergelijken in plaats van af te gaan op algemene berichten in de console.
Stel stopvoorwaarden vast en sluit af met een rapport
Stop de hervatting als er sleutelconflicten zijn, ongeldige gegevens waarvoor een businessregel nodig is, verweesde relaties, onzekere resultaten die niet kunnen worden geverifieerd of verschillen die de geaccepteerde grenzen overschrijden. Stop ook als het beschikbare bewijs niet duidelijk maakt wat er is gebeurd. In zulke gevallen is escaleren en de huidige status bewaren doorgaans veiliger dan blind opnieuw proberen.
Voer na afloop de globale controles uit: bevestigde eenheden tegenover verwachte eenheden, aantallen en sleutels, relaties en de businessregels die voor de migratie zijn vastgelegd. Genereer een rapport met daarin wat is gemigreerd, wat is geverifieerd, wat opnieuw is geprobeerd en welke afwijkingen nog openstaan, inclusief verwijzingen waarmee ze kunnen worden onderzocht. Verklaar het werk niet afgerond alleen omdat het proces met exitcode nul is beëindigd.
Het criterium voor hervatting is eenvoudig te verwoorden, al vergt het technische discipline: elke eenheid moet zijn bevestigd, als niet toegepast zijn geverifieerd of apart zijn gezet voor controle. Die expliciete status, in combinatie met vergelijkbare invarianten en bruikbare logboeken, maakt het mogelijk een PHP-migratie voort te zetten zonder voortgang met succes te verwarren of onzekerheid te zien als toestemming om de bewerking te herhalen.
