Una migrazione interrotta non è sempre semplicemente «a metà». Potrebbe essersi fermata prima di salvare un’unità, dopo aver confermato alcune modifiche o mentre la risposta del sistema di destinazione era ambigua. Potrebbe anche aver completato il processo lasciando comunque delle discrepanze. Per decidere come procedere, il team deve ricostruire ciò che è accaduto sulla base di evidenze verificabili, senza affidarsi soltanto al codice di uscita o all’ultimo identificativo registrato.
La domanda pratica non è solo come riprendere una migrazione di dati PHP non riuscita, ma anche cosa si può affermare sullo stato di ogni unità e quali verifiche sono necessarie prima di ripetere un’operazione. Questa distinzione riduce il rischio di duplicati, relazioni interrotte e correzioni manuali difficili da sottoporre ad audit.
Per prima cosa, distingui un’esecuzione interrotta da una migrazione con discrepanze
Un’esecuzione interrotta è un’esecuzione il cui processo ha smesso di avanzare, per esempio a causa di un’eccezione, di una perdita di connessione o di un intervento operativo. Una migrazione con discrepanze, invece, è una migrazione il cui risultato non soddisfa le condizioni attese, anche se il processo è terminato senza errori. Potrebbero esserci righe omesse, chiavi trasformate in modo errato o relazioni incomplete.
Per questo, uno stato globale come completata o non riuscita non è sufficiente. È opportuno distinguere almeno tra esecuzione in corso, interrotta, completata e completata con discrepanze. Lo stato globale riassume il lavoro, ma non sostituisce il registro per unità né la convalida del risultato.
Prima di rilanciare il comando, conserva i registri disponibili e determina quale sistema è la fonte di verità in questa fase. Se dopo la migrazione sono state effettuate scritture, modifiche manuali o processi concorrenti, individua in che modo influiscono sul confronto. Procedere senza queste informazioni può trasformare una discrepanza su cui è possibile indagare in una perdita di tracciabilità.
Definisci unità di lavoro e punti di controllo verificabili
Scegli un’unità di lavoro che abbia senso per i dati e per il ripristino: può essere un’entità, un gruppo di record correlati o una partizione stabile. Evita che il punto di controllo sia semplicemente «l’ultimo ID elaborato». Al massimo, quell’ID dimostra che il programma ha raggiunto una certa posizione; non prova che tutti i record precedenti siano stati salvati correttamente né che i dati di destinazione siano coerenti.
Per ogni unità, conserva una chiave di origine stabile, la versione o l’identificativo dell’esecuzione, lo stato e un risultato verificabile. Il punto di controllo deve poter essere confrontato con i dati di destinazione, per esempio tramite una chiave di destinazione, un’impronta calcolata sui campi rilevanti o una query di verifica. Se i dati possono cambiare durante il processo, registra anche il criterio di selezione o l’istante di cutoff applicato.
La progettazione dipende dall’ambiente. Se origine e destinazione condividono una transazione, questa può fornire evidenza della conferma congiunta; se sono sistemi diversi, non dare per scontata l’atomicità tra i due. In un’integrazione tramite API, una risposta persa può lasciare incerto se il server abbia applicato l’operazione. La strategia deve tenere conto di questa incertezza e prevedere una verifica successiva, anziché contrassegnare automaticamente l’unità come non riuscita o confermata.
Registra per ogni unità cosa è stato tentato e cosa è stato confermato
Un registro utile per il supporto permette di rispondere a queste domande: chi ha eseguito la migrazione, quale unità ha elaborato, quando è cambiato il suo stato e con quali evidenze. Distingui tra elaborato — il codice ha eseguito dei passaggi — e confermato — esiste un segnale affidabile che il risultato atteso è presente nella destinazione. Aggiungi il numero del tentativo, una categoria di errore e un identificativo di correlazione per collegare gli eventi del processo alle chiamate esterne.
Gli stati devono descrivere situazioni operative, non soltanto fasi dell’algoritmo. Per esempio: in attesa, in corso, conferma incerta, confermato e richiede revisione. Se il processo si arresta mentre un’unità risulta in corso, al riavvio l’unità va considerata incerta finché la destinazione non è stata verificata. Non contrassegnarla come non riuscita senza aver verificato se abbia prodotto effetti.
Registra informazioni sufficienti per svolgere un’indagine, ma non inserire nei log credenziali, segreti o dati personali non necessari. Gli errori devono permettere di identificare l’unità e l’operazione, senza che la tracciabilità aumenti l’esposizione dei dati. Definisci anche chi può consultare e conservare questi registri.
Confronta le invarianti prima di decidere come procedere
Le invarianti sono condizioni che devono essere rispettate indipendentemente dall’implementazione della migrazione. I conteggi per tipo o partizione aiutano a individuare le differenze, ma non bastano: due insiemi possono avere le stesse dimensioni e contenere record diversi. Confronta le chiavi di business, la presenza dei record, le relazioni e le regole rilevanti, come gli stati consentiti o gli importi ricalcolati.
Scegli verifiche proporzionate all’impatto e al volume. Un campione può essere utile per la diagnosi, ma da solo non dimostra che l’intero insieme sia corretto. Per una convalida esaustiva, confronta le chiavi o le impronte a blocchi e registra quali sono stati verificati. Se la trasformazione modifica intenzionalmente alcuni campi, documenta quali differenze sono previste e quali indicano un errore.
Se l’origine continua a ricevere modifiche, separa le discrepanze dovute alla concorrenza da quelle causate dalla migrazione. Potrebbe essere necessario fissare una finestra di cutoff, acquisire le modifiche successive o ripetere una fase di sincronizzazione. Senza una regola chiara per gestire le modifiche concorrenti, il confronto tra sistemi può generare falsi positivi o non rilevare dati nuovi.
Riprendi solo sulla base di evidenze e gestisci i risultati incerti
Una ripresa sicura carica le unità in attesa e quelle confermate, ma non considera valide quelle rimaste in uno stato incerto. Per queste ultime, interroga la destinazione usando una chiave stabile e confronta il risultato con la trasformazione attesa. Se corrisponde, registra la conferma senza ripetere l’effetto; se non esiste, può essere opportuno riprovare. Se esiste con contenuti diversi, interrompi l’elaborazione di quell’unità e svolgi un’indagine.
Quando ripetere un’operazione può creare duplicati o effetti esterni — come l’invio di una notifica — utilizza un’operazione idempotente o una chiave di idempotenza, se il sistema coinvolto la supporta. Se non è possibile, progetta un controllo preliminare e una procedura di riconciliazione. Non dare per scontato che un’eccezione significhi che non sia stato scritto nulla: l’errore potrebbe essersi verificato dopo la conferma della modifica ma prima della ricezione della risposta.
Prima di riprendere, verifica che vengano utilizzati la stessa mappatura, la stessa policy delle chiavi e la versione corretta del codice o della configurazione. Un punto di controllo generato da una trasformazione diversa può essere fuorviante. In PHP, il comando di migrazione dovrebbe accettare un identificativo dell’esecuzione ed emettere stati strutturati; in questo modo, una persona può confrontare il registro con i dati, anziché affidarsi a messaggi generici nella console.
Definisci le condizioni di arresto e concludi con un rapporto
Interrompi la prosecuzione in presenza di conflitti tra chiavi, dati non validi che richiedono una regola di business, relazioni orfane, risultati incerti che non possono essere verificati o differenze che superano i limiti accettati. Fermati anche se le evidenze disponibili non permettono di stabilire cosa sia accaduto. In questi casi, inoltrare il problema e preservare lo stato è spesso più sicuro che riprovare alla cieca.
Al termine, esegui i controlli globali: unità confermate rispetto a quelle attese, conteggi e chiavi, relazioni e regole di business definite per la migrazione. Genera un rapporto che indichi cosa è stato migrato, cosa è stato verificato, cosa è stato ripetuto e quali discrepanze sono ancora in sospeso, con riferimenti che permettano di indagare. Non dichiarare concluso il lavoro solo perché il processo è terminato con codice zero.
Il criterio per riprendere è semplice da esprimere, anche se richiede disciplina tecnica: ogni unità deve risultare confermata, verificata come non applicata oppure messa da parte per una revisione. Questo stato esplicito, insieme a invarianti confrontabili e registri utili, permette di continuare una migrazione PHP senza confondere l’avanzamento con il successo né l’incertezza con l’autorizzazione a ripetere l’operazione.
