Błąd podczas replikacji

Błąd podczas replikacji sygnalizuje niepowodzenie procesu synchronizacji danych pomiędzy wydawcą a subskrybentami.

Na czym polega błąd podczas replikacji

Błąd podczas replikacji oznacza, że system nie zdołał prawidłowo przekazać albo zastosować zmian danych między źródłem a jednym lub większą liczbą odbiorców. W zależności od architektury źródło może być nazywane wydawcą, węzłem nadrzędnym albo liderem, natomiast odbiorca może pełnić rolę subskrybenta, repliki lub węzła podrzędnego. Replikowane mogą być całe zbiory danych, wybrane tabele, dzienniki zmian, obiekty katalogowe albo komunikaty opisujące operacje wykonane w systemie źródłowym.

Samo pojawienie się komunikatu o błędzie nie określa jeszcze przyczyny awarii. Problem może wystąpić podczas odczytu zmian ze źródła, przesyłania ich przez sieć, zapisu w kolejce, uwierzytelniania połączenia lub wykonywania operacji na subskrybencie. Istotne jest również rozróżnienie między chwilowym opóźnieniem a trwałym zatrzymaniem synchronizacji. Opóźnienie oznacza, że odbiorca nadal może nadrabiać zaległości, natomiast zatrzymany proces wymaga ustalenia miejsca, w którym przepływ zmian został przerwany.

Najczęstsze miejsca powstawania niespójności

Jedną z przyczyn jest utrata albo niestabilność połączenia między uczestnikami replikacji. Zerwanie sesji może nastąpić wskutek niedostępności hosta, błędnego adresu, problemu z rozwiązywaniem nazw, blokady portu sieciowego, przekroczenia limitu czasu lub przeciążenia jednego z systemów. Jeżeli mechanizm wykorzystuje szyfrowane połączenie, dodatkowym źródłem problemu może być nieważny certyfikat, niezgodny protokół szyfrowania albo brak zaufania do urzędu certyfikacji.

Awaria może powstać także po stronie danych. Operacja zaakceptowana w źródle może zostać odrzucona w replice z powodu naruszenia klucza unikatowego, braku wymaganej kolumny, odmiennego typu danych, niezgodności ograniczenia integralności lub konfliktu z lokalną zmianą. Podobny skutek może mieć usunięcie obiektu oczekiwanego przez proces replikacji, zmiana uprawnień konta technicznego albo wyczerpanie miejsca na dysku. W replikacji opartej na dzienniku zmian uszkodzenie, przedwczesne usunięcie lub niedostępność właściwego fragmentu dziennika może uniemożliwić kontynuowanie od wskazanego punktu.

Jak odczytywać objawy i kolejność zdarzeń

Diagnostykę należy rozpocząć od ustalenia, czy błąd dotyczy jednego odbiorcy, czy całej topologii. Jeżeli wszystkie repliki przestały otrzymywać zmiany w podobnym czasie, bardziej prawdopodobny jest problem ze źródłem, wspólną usługą pośredniczącą, siecią albo konfiguracją uwierzytelniania. Jeżeli problem występuje tylko w jednej replice, należy sprawdzić jej stan lokalny, dostępne zasoby, ostatnią prawidłowo zastosowaną zmianę oraz różnice konfiguracji względem pozostałych odbiorców.

W komunikatach diagnostycznych ważne są znaczniki czasu, identyfikator zadania, nazwa uczestnika, numer albo pozycja przetwarzanej zmiany oraz pełny komunikat błędu. Należy analizować pierwszą przyczynę w łańcuchu zdarzeń, a nie wyłącznie późniejsze komunikaty o opóźnieniu. Przykładowo błąd zapisu na dysku może później powodować narastanie kolejki, przekroczenie limitu czasu i utratę połączenia. Porównanie logów źródła, procesu przesyłającego i odbiorcy pozwala ustalić, czy zmiana została utworzona, odczytana, wysłana, odebrana oraz zatwierdzona.

Bezpieczne przywracanie synchronizacji

Po ustaleniu przyczyny należy najpierw usunąć przeszkodę: przywrócić dostępność usługi, poprawić trasę sieciową, odnowić uprawnienia, zwiększyć dostępne miejsce lub skorygować zgodność schematu danych. Ponowienie zadania bez diagnozy może powielać ten sam błąd, zwiększać kolejkę oczekujących zmian albo utrudnić rozpoznanie pierwotnego zdarzenia. Nie powinno się ręcznie usuwać wpisów z dzienników replikacji ani modyfikować danych w replice bez sprawdzenia, jak dany mechanizm interpretuje takie zmiany.

Jeżeli odbiorca utracił wymagany zakres historii zmian, może być konieczna ponowna inicjalizacja repliki z aktualnego obrazu źródła. Taka operacja nie jest tym samym co zwykłe wznowienie procesu i wymaga sprawdzenia kopii zapasowej, kompletności danych oraz kolejności dalszych zmian. Po naprawie należy potwierdzić, że kolejka replikacji maleje, proces przetwarza nowe zmiany, a dane po obu stronach są zgodne według właściwych dla danego systemu kryteriów. W środowisku z danymi użytkowymi warto zachować logi i informacje o wykonanych działaniach, aby można było odtworzyć przebieg awarii oraz zweryfikować, czy nie wystąpiła częściowa utrata synchronizacji. Jeżeli przyczyną problemów z synchronizacją jest stanowisko komputerowe, a nie sama usługa, Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną diagnostyką i naprawą laptopów oraz komputerów PC w tym zakresie.