Een migratie kan miljoenen records wijzigen, actieve processen van gegevens voorzien en effecten buiten de database veroorzaken. Als een transformatie halverwege mislukt, is een volledige back-up terugzetten niet altijd veilig of aanvaardbaar: mogelijk zijn er na het maken van de back-up nieuwe gegevens opgeslagen, of kan het systeem niet zo lang worden stilgelegd als voor het herstel nodig is.
Daarom mag een rollbackplan voor datamigraties niet neerkomen op één opdracht om terug te draaien. Het moet vastleggen hoe de getroffen status wordt vastgesteld, welke bewerkingen ongedaan kunnen worden gemaakt, welke compensatie vereisen en wanneer herstellen of hervatten de beste keuze is. De beslissing wordt voorbereid voordat de migratie wordt uitgevoerd, aan de hand van criteria die het team onder druk kan controleren.
Waarom een back-up terugzetten niet altijd een haalbare rollback is
Een back-up helpt gegevens bij bepaalde incidenten te herstellen, maar het terugzetten ervan kan legitieme wijzigingen verwijderen die na het maken van de back-up zijn aangebracht. Het kan ook leiden tot downtime, het opnieuw opbouwen van indexen of het verlies van schrijfbewerkingen die andere systemen hebben bereikt. Bij replicatie, wachtrijen, exports of integraties worden die effecten niet automatisch teruggedraaid door een database te herstellen.
Maak onderscheid tussen drie handelingen. Herstellen betekent herstellen vanaf een back-up of naar een bepaald tijdstip; terugdraaien probeert de wijzigingen van de migratie ongedaan te maken; compenseren voert nieuwe bewerkingen uit om de effecten ervan te corrigeren. Dit is niet hetzelfde: compensatie kan een andere geschiedenis opleveren dan het origineel, ook als de bedrijfsregels weer worden nageleefd.
De keuze hangt af van de omvang van de fout, latere schrijfbewerkingen en de hersteldoelen. Bepaal vóór de start welk gegevensverlies aanvaardbaar is, hoelang de onderbreking mag duren en wie herstel goedkeurt. Als die grenzen niet zijn vastgesteld, heeft het team geen operationeel criterium om een beslissing te nemen.
Elke transformatie classificeren op herstelbaarheid
Beschrijf elke stap van de migratie en classificeer deze op basis van de beoogde herstelmethode:
- Omkeerbaar: er bestaat een betrouwbare inverse bewerking. Zo kan de oorspronkelijke waarde worden bewaard voordat een veld wordt genormaliseerd en later worden teruggezet zonder latere wijzigingen te overschrijven.
- Compenseerbaar: de eerdere status kan niet exact worden gereconstrueerd, maar een nieuwe bewerking kan het effect corrigeren volgens een bedrijfsregel. De compensatie moet expliciet en controleerbaar zijn en waar mogelijk idempotent.
- Onomkeerbaar: er gaat informatie verloren of er treedt een effect op dat niet met garanties ongedaan kan worden gemaakt. Dit vereist een expliciete beslissing over risicoacceptatie, het bewaren van brongegevens en aanvullende validaties.
Ken de classificatie niet alleen toe op basis van het type SQL-instructie. Een bulkupdate kan omkeerbaar zijn als de vorige waarde wordt opgeslagen en concurrency wordt beheerst; dat hoeft niet zo te zijn als andere processen tijdens de uitvoering dezelfde rijen wijzigen. Houd ook rekening met neveneffecten zoals meldingen, API-aanroepen, betalingen of berichten in wachtrijen. Vaak is het beter om die acties los te koppelen van de datatransformatie.
De beginsituatie en invarianten vastleggen
Leg vóór de uitvoering de reikwijdte van de migratie vast: opgenomen entiteiten, filters, applicatieversie en toegepaste regels. Bepaal een baseline met relevante aantallen en, als dat waarde toevoegt, aggregaties of fingerprints van stabiele sets. Noteer het referentietijdstip en de bron van die gegevens. Een getal zonder reikwijdte of context maakt herstel niet verifieerbaar.
Invarianten zijn voorwaarden die tijdens en na de migratie waar moeten blijven. Dit kunnen relaties tussen tabellen zijn, uniciteit, toegestane statussen, bedragen die behouden moeten blijven of de overeenstemming tussen database-records en aangesloten systemen. Voeg aan elke invariant een reproduceerbare query of procedure en een acceptatiedrempel toe. Als gegevens tijdens de uitvoering legitiem veranderen, bepaal dan hoe die activiteit kan worden onderscheiden van het effect van de migratie.
In een PHP-applicatie kunnen transformaties worden geïmplementeerd in consolecommando's of workerprocessen, in plaats van afhankelijk te zijn van een langlopende webrequest. Die keuze neemt de risico's van concurrency of de grenzen van transacties niet weg: bepaal welke eenheid atomair kan worden uitgevoerd en wat er moet gebeuren als het proces tussen twee bewerkingen eindigt.
Batches, checkpoints en hervatbare uitvoering ontwerpen
Verdeel het werk in batches met expliciete grenzen, bijvoorbeeld op basis van een stabiele, geordende sleutel. Vermijd paginering met offsets als rijen tijdens het proces kunnen veranderen of verdwijnen; een vervolgmarkering op basis van een sleutel is doorgaans voorspelbaarder. De batchgrootte moet een evenwicht bieden tussen de transactieduur, de belasting van de database en het gemak waarmee fouten kunnen worden opgespoord.
Sla na elke batch een checkpoint op met de job-ID, het verwerkte bereik, de status, het tijdstip en de validatieresultaten. Het bijwerken van de gegevens en het opschuiven van het checkpoint moeten op elkaar worden afgestemd, zodat een batch niet als verwerkt wordt gemarkeerd voordat deze is bevestigd. Als beide bewerkingen niet binnen één transactie kunnen plaatsvinden, ontwerp dan een reconciliatieprocedure om de tussentoestand te detecteren.
Een hervatbare migratie past wijzigingen niet blind opnieuw toe. Elke bewerking moet retries verdragen of controleren of het effect al bestaat. In PHP kan dit, afhankelijk van de database-engine en het datamodel, worden ondersteund met transacties, unique constraints en idempotente bewerkingen. Test ook opzettelijke onderbrekingen: een deployment, exception of verbindingsverlies mag het werk niet achterlaten zonder bekende manier om verder te gaan.
Wijzigingen registreren om effecten te traceren en beslissingen te auditen
Ken elke uitvoering een unieke ID toe en registreer minimaal de transformatie, de reikwijdte, de batches, de getroffen rijen, de fouten en de herstelbeslissingen. Bewaar voor wijzigingen die kunnen worden gecompenseerd de benodigde vorige gegevens of een veilige verwijzing ernaar. Leg niet zonder onderscheid gevoelige informatie vast in logs; beperk de toegang, bewaartermijn en inhoud tot wat nodig is voor herstel en audit.
Het log moet antwoord geven op concrete vragen: welke rijen zijn geprobeerd te verwerken, welke rijen zijn bevestigd en welke rijen zijn mislukt? En welke latere bewerking heeft die rijen gewijzigd? Combineer technische logs waar nodig met een geschiedenis van bedrijfswijzigingen. Verwar traceerbaarheid niet met een back-up: het log moet voldoende details bevatten voor het beoogde doel en moet ook tegen verlies of wijziging worden beschermd.
Kiezen tussen hervatten, compenseren of herstellen
Leg signalen en reacties vooraf vast, in plaats van bij een fout uitsluitend op intuïtie af te gaan:
- Hervatten: als de fout tijdelijk is, de invarianten intact zijn en bekend is welke batches zijn bevestigd. Voer een beperkt aantal retries uit en houd fouten en belasting in de gaten.
- Compenseren: als de toegepaste wijzigingen bekend zijn en er een geteste correctieve bewerking bestaat. Stop eerst nieuwe, incompatibele schrijfbewerkingen en controleer of de compensatie geldige wijzigingen niet overschrijft.
- Herstellen: als de corruptie omvangrijk is, herstel vanaf een back-up is gevalideerd en de impact van het verlies of opnieuw opbouwen van latere wijzigingen aanvaardbaar is. Stem het herstel af met replica's en integraties.
- Stoppen en escaleren: als de status niet kan worden vastgesteld, aantallen zonder verklaring uiteenlopen of compensatie meer schade kan veroorzaken. Bewaar bewijsmateriaal voordat je ingrijpt.
Stel drempelwaarden vast om het werk te pauzeren, zoals een foutpercentage boven de toegestane limiet, een geschonden invariant of afwijkende aantallen. Bepaal wie hervatting mag goedkeuren en wie over herstel beslist. Soms is de veiligste optie om de getroffen stroom te isoleren en het systeem in een gecontroleerde status te houden terwijl het onderzoek loopt.
De migratie valideren en afsluiten met een checklist
Dat het proces is voltooid, bewijst niet dat de gegevens correct zijn. Vergelijk aantallen vóór en na de migratie met de verwachte reikwijdte, voer bedrijfsregels uit en controleer relaties en extreme waarden. Gebruik steekproeven om specifieke gevallen te inspecteren, maar niet als vervanging voor volledige controles wanneer die mogelijk zijn. Als er externe afnemers zijn, controleer dan ook hun status en spreek af hoe verschillen worden gereconcilieerd.
Vóór uitvoering: classificeer transformaties, bevestig back-up en herstelmogelijkheden, test batches en retries met representatieve gegevens en bepaal invarianten, stopgrenzen, verantwoordelijken en het uitvoeringsvenster. Zorg dat het team het wijzigingslog kan raadplegen en dat compensatie- of herstelprocedures zijn getest.
Na uitvoering: valideer aantallen en regels, controleer fouten en externe effecten, bewaar het uitvoeringslog en documenteer eventuele uitzonderingen. Houd herstelgegevens beschikbaar gedurende de afgesproken periode en verwijder ze veilig zodra ze niet meer nodig zijn. De migratie is pas afgesloten wanneer de resultaten verifieerbaar zijn en er een expliciet besluit is genomen over openstaande afwijkingen.
