Przerwana migracja nie zawsze jest po prostu „niedokończona”. Mogła zatrzymać się przed zapisaniem jednostki, po zatwierdzeniu części zmian albo w sytuacji, gdy system docelowy odpowiedział w niejednoznaczny sposób. Mogła też zakończyć działanie, a mimo to pozostawić rozbieżności. Aby zdecydować, jak kontynuować, zespół musi odtworzyć przebieg zdarzeń na podstawie weryfikowalnych dowodów, a nie polegać wyłącznie na kodzie wyjścia czy ostatnim zarejestrowanym identyfikatorze.
Praktyczne pytanie nie brzmi tylko: jak wznowić nieudaną migrację danych w PHP, lecz także: co można stwierdzić o stanie każdej jednostki i jakie kontrole należy przeprowadzić przed ponowieniem operacji. To rozróżnienie ogranicza ryzyko duplikatów, zerwanych relacji i ręcznych korekt, które trudno poddać audytowi.
Najpierw odróżnij zatrzymane wykonanie od migracji z rozbieżnościami
Zatrzymane wykonanie to takie, w którym proces przestał robić postępy, na przykład z powodu wyjątku, utraty połączenia lub interwencji operacyjnej. Migracja z rozbieżnościami to natomiast taka, której wynik nie spełnia oczekiwanych warunków, nawet jeśli proces zakończył się bez błędów. Mogło dojść do pominięcia wierszy, nieprawidłowego przekształcenia kluczy albo niekompletnego odtworzenia relacji.
Dlatego ogólny status, taki jak zakończona lub nieudana, nie wystarcza. Warto rozróżniać co najmniej stany: w toku, zatrzymana, zakończona oraz zakończona z rozbieżnościami. Status ogólny podsumowuje pracę, ale nie zastępuje rejestru poszczególnych jednostek ani walidacji wyniku.
Przed ponownym uruchomieniem polecenia zachowaj dostępne logi i ustal, który system jest na tym etapie źródłem prawdy. Jeśli po migracji odbywały się zapisy, wprowadzano ręczne zmiany lub działały procesy współbieżne, określ, jaki mają wpływ na porównanie. Kontynuowanie bez tych informacji może zamienić możliwą do zbadania rozbieżność w utratę identyfikowalności przebiegu migracji.
Zdefiniuj jednostki pracy i weryfikowalne punkty kontrolne
Wybierz jednostkę pracy odpowiednią dla danych i procesu odzyskiwania: może to być encja, powiązana grupa rekordów lub stabilna partycja. Nie traktuj punktu kontrolnego jako zwykłego „ostatniego przetworzonego ID”. Taki identyfikator dowodzi co najwyżej, że program dotarł do określonego miejsca; nie potwierdza, że wszystkie wcześniejsze rekordy zostały poprawnie zapisane ani że dane docelowe są spójne.
Dla każdej jednostki zachowaj stabilny klucz źródłowy, wersję lub identyfikator wykonania, status i weryfikowalny wynik. Punkt kontrolny powinien dać się porównać z danymi docelowymi, na przykład za pomocą klucza docelowego, skrótu obliczonego na podstawie istotnych pól lub zapytania weryfikacyjnego. Jeśli dane mogą zmieniać się w trakcie procesu, zapisuj również zastosowane kryterium wyboru lub moment odcięcia.
Projekt rozwiązania zależy od środowiska. Jeśli źródło i cel korzystają ze wspólnej transakcji, może ona dostarczyć dowodu wspólnego zatwierdzenia; jeśli są to różne systemy, nie zakładaj atomowości między nimi. W integracji przez API utracona odpowiedź może pozostawić niepewność, czy serwer wykonał operację. Strategia powinna uwzględniać tę niepewność i umożliwiać późniejszą weryfikację, zamiast automatycznie oznaczać jednostkę jako nieudaną lub potwierdzoną.
Rejestruj dla każdej jednostki, czego próbowano i co potwierdzono
Przydatny z punktu widzenia wsparcia rejestr pozwala ustalić, kto uruchomił migrację, którą jednostkę przetwarzał, kiedy zmienił się jej status i jakie są na to dowody. Rozróżniaj przetworzone — kod wykonał kolejne kroki — od potwierdzone — istnieje wiarygodny sygnał, że oczekiwany wynik znajduje się w systemie docelowym. Dodaj numer próby, kategorię błędu i identyfikator korelacyjny łączący zdarzenia procesu z wywołaniami zewnętrznymi.
Statusy powinny opisywać sytuacje operacyjne, a nie tylko etapy algorytmu. Mogą to być na przykład: oczekująca, w toku, niepewne potwierdzenie, potwierdzona, wymaga weryfikacji. Jeśli proces zakończy działanie, gdy jednostka ma status „w toku”, po ponownym uruchomieniu należy traktować ją jako niepewną, dopóki nie zostaną zweryfikowane dane docelowe. Nie oznaczaj jej jako nieudanej bez sprawdzenia, czy wywołała skutki.
Rejestruj wystarczająco dużo informacji, aby umożliwić analizę, ale nie zapisuj w logach danych uwierzytelniających, sekretów ani zbędnych danych osobowych. Błędy powinny pozwalać zidentyfikować jednostkę i operację, nie zwiększając przy tym ekspozycji danych przez samo śledzenie przebiegu. Określ również, kto może przeglądać i przechowywać te logi.
Porównaj niezmienniki, zanim zdecydujesz, jak kontynuować
Niezmienniki to warunki, które muszą być spełnione niezależnie od implementacji migracji. Liczby rekordów według typu lub partycji pomagają lokalizować różnice, ale nie wystarczają: dwa zbiory mogą mieć taką samą liczebność, a zawierać różne rekordy. Porównuj klucze biznesowe, obecność rekordów, relacje i istotne reguły, takie jak dozwolone statusy czy ponownie obliczone kwoty.
Dobierz kontrole do wpływu zmian i wolumenu danych. Próbka może pomóc w diagnozie, ale sama nie dowodzi poprawności całego zbioru. Przy pełnej walidacji porównuj klucze lub skróty partiami i rejestruj, które elementy sprawdzono. Jeśli transformacja celowo zmienia pola, udokumentuj, które różnice są oczekiwane, a które wskazują na błąd.
Jeśli w źródle nadal pojawiają się zmiany, oddziel rozbieżności wynikające ze współbieżności od tych spowodowanych migracją. Może być konieczne ustalenie okna odcięcia, przechwycenie późniejszych zmian lub ponowienie fazy synchronizacji. Bez jasnej reguły obsługi zmian współbieżnych porównanie systemów może prowadzić do fałszywych alarmów albo pomijać nowe dane.
Wznawiaj tylko na podstawie dowodów i obsługuj niepewne wyniki
Bezpieczne wznowienie uwzględnia jednostki oczekujące i potwierdzone, ale nie uznaje za poprawne tych, których stan jest niepewny. W przypadku tych ostatnich sprawdź system docelowy za pomocą stabilnego klucza i porównaj wynik z oczekiwaną transformacją. Jeśli wynik się zgadza, zarejestruj jego potwierdzenie bez ponawiania efektu; jeśli go nie ma, ponowna próba może być właściwa. Jeśli istnieje, ale ma inną zawartość, wstrzymaj przetwarzanie tej jednostki i zbadaj problem.
Jeśli ponowienie operacji może utworzyć duplikaty lub wywołać efekty zewnętrzne — takie jak wysłanie powiadomienia — zastosuj operację idempotentną albo klucz idempotencji, jeśli obsługuje go dany system. Jeśli to niemożliwe, zaprojektuj kontrolę wstępną i ścieżkę uzgadniania danych. Nie zakładaj, że wyjątek oznacza brak zapisu: błąd mógł wystąpić po zatwierdzeniu zmiany, ale przed otrzymaniem odpowiedzi.
Przed wznowieniem sprawdź, czy używane są to samo mapowanie, ta sama polityka kluczy oraz właściwa wersja kodu lub konfiguracji. Punkt kontrolny wygenerowany przez inną transformację może wprowadzać w błąd. W PHP polecenie migracji powinno przyjmować identyfikator pozwalający jednoznacznie zidentyfikować konkretne uruchomienie i emitować ustrukturyzowane statusy; dzięki temu można porównać rejestr z danymi, zamiast polegać na ogólnych komunikatach w konsoli.
Ustal warunki zatrzymania i zakończ pracę raportem
Wstrzymaj kontynuację w przypadku konfliktów kluczy, nieprawidłowych danych wymagających reguły biznesowej, osieroconych relacji, niepewnych wyników, których nie można zweryfikować, lub różnic przekraczających dopuszczalne limity. Zatrzymaj proces również wtedy, gdy dostępne dowody nie pozwalają ustalić, co się wydarzyło. W takich przypadkach eskalacja problemu i zachowanie bieżącego stanu są zwykle bezpieczniejsze niż ponawianie operacji na ślepo.
Po zakończeniu wykonaj kontrole całościowe: porównaj liczbę potwierdzonych jednostek z oczekiwaną, sprawdź liczby i klucze, relacje oraz reguły biznesowe określone dla migracji. Przygotuj raport wskazujący, co zmigrowano, co zweryfikowano, co ponowiono i jakie rozbieżności nadal wymagają rozwiązania, wraz z odnośnikami ułatwiającymi ich analizę. Nie uznawaj pracy za zakończoną tylko dlatego, że proces zakończył się kodem zero.
Kryterium wznowienia można łatwo sformułować, choć jego spełnienie wymaga technicznej dyscypliny: każda jednostka musi zostać potwierdzona, zweryfikowana jako niezaaplikowana albo odłożona do przeglądu. Taki jawny status, wraz z porównywalnymi niezmiennikami i użytecznymi rejestrami, pozwala kontynuować migrację w PHP bez utożsamiania postępu z sukcesem ani niepewności z upoważnieniem do ponowienia operacji.
