Awaria replikacji

Awaria replikacji to zdarzenie zakłócające prawidłowy proces synchronizacji danych między wydawcą a subskrybentami.

Na czym polega awaria replikacji

Awaria replikacji oznacza przerwanie albo zniekształcenie procesu, w którym dane z systemu źródłowego są przekazywane do jednego lub wielu systemów docelowych. W terminologii baz danych źródło bywa nazywane wydawcą, a odbiorcy subskrybentami. W innych rozwiązaniach spotyka się określenia lider i repliki, węzeł podstawowy i zapasowy albo master i replica. Niezależnie od nazewnictwa mechanizm ma zapewnić, że zmiany wykonane w jednym miejscu zostaną odczytane i zastosowane w pozostałych miejscach.

Nie każda różnica między systemem źródłowym a repliką oznacza ten sam rodzaj problemu. Opóźnienie replikacji może być przejściowe, jeżeli odbiorca nadal pobiera i przetwarza zmiany. Poważniejsza sytuacja występuje wtedy, gdy kolejka zmian rośnie, proces zatrzymuje się, występuje błąd uwierzytelniania lub replika nie może zastosować konkretnej operacji. Jeszcze inny przypadek to utrata części historii zmian, uszkodzenie danych albo rozbieżność logiczna, w której oba systemy działają, lecz zawierają inne wartości.

Objawy widoczne w systemie źródłowym i replice

Podstawowym objawem jest rozbieżność czasu między zapisaniem zmiany a jej pojawieniem się na replice. Może ona dotyczyć pojedynczych rekordów, całych tabel, plików albo komunikatów zależnie od użytego mechanizmu. W monitoringu pojawiają się wtedy informacje o opóźnieniu, nieprzetworzonych zdarzeniach, zatrzymanym zadaniu, błędzie połączenia lub braku potwierdzenia odbioru. Jeżeli replikacja działa asynchronicznie, system źródłowy może przyjmować nowe zapisy mimo czasowej niedostępności odbiorcy, ale zaległe zmiany muszą zostać później dostarczone i zastosowane.

W replikacji synchronicznej problem z odbiorcą może natomiast bezpośrednio wpływać na możliwość zatwierdzania operacji po stronie źródła. Typowym skutkiem jest wydłużenie czasu odpowiedzi, blokowanie transakcji lub odrzucanie zapisu. W replikacji jednokierunkowej zmiany płyną głównie od wydawcy do subskrybenta, natomiast w układzie wielokierunkowym możliwe są konflikty wynikające z jednoczesnej modyfikacji tego samego obiektu w kilku miejscach. Sam fakt, że proces techniczny jest uruchomiony, nie dowodzi więc poprawnej synchronizacji.

Rozbieżność może ujawnić się także pośrednio. Użytkownik widzi na jednym stanowisku aktualną konfigurację, a na innym poprzednią wersję danych. Raport odczytany z repliki może nie zawierać ostatnich wpisów, a przełączenie na system zapasowy może ujawnić brak niedawno zatwierdzonych zmian. Dlatego podczas oceny awarii trzeba ustalić, który system zawiera wersję referencyjną, z jakiego momentu pochodzi ostatnia potwierdzona synchronizacja oraz czy dane były modyfikowane po wystąpieniu problemu.

Najczęstsze przyczyny zatrzymania synchronizacji

Jedną z grup przyczyn są problemy komunikacyjne: niedostępność hosta, błędny adres, zamknięty port, zerwane połączenie, nieprawidłowa konfiguracja szyfrowania albo niewłaściwa rozdzielczość nazwy. Nawet chwilowa utrata łączności może spowodować nagromadzenie zmian w buforze lub dzienniku. Jeżeli pojemność tego obszaru zostanie przekroczona albo wymagane wpisy zostaną usunięte przed ich odebraniem, samo przywrócenie połączenia może nie wystarczyć do automatycznego nadrobienia zaległości.

Druga grupa obejmuje błędy dostępu i zgodności. Konto używane przez proces replikacji może utracić uprawnienia, wygasnąć albo zostać zablokowane. Różnice schematu, brak obiektu docelowego, naruszenie ograniczenia unikalności, konflikt klucza, niezgodny typ danych lub zmiana struktury tabeli mogą uniemożliwić zastosowanie jednego zdarzenia. W systemach opartych na dziennikach problemem bywa także uszkodzenie lub niedostępność pliku dziennika, brak wolnego miejsca oraz niespójność metadanych opisujących pozycję, od której należy kontynuować odczyt.

Wydajność również może doprowadzić do pozornego zatrzymania. Jeżeli odbiorca przetwarza zmiany wolniej, niż źródło je generuje, opóźnienie stale rośnie. Przyczyną może być przeciążenie procesora, pamięci masowej, pamięci operacyjnej albo sieci, a także blokady transakcyjne i długo trwające operacje. Osobnego traktowania wymaga konflikt danych. W replikacji wielokierunkowej dwa różne zapisy mogą dotyczyć tego samego rekordu; system musi wtedy zastosować ustaloną regułę rozstrzygania albo zatrzymać przetwarzanie do czasu decyzji operatora.

Bezpieczna diagnostyka i przywracanie spójności

Diagnostykę zaczyna się od zebrania czasu wystąpienia problemu, identyfikatora zadania lub kanału replikacji oraz komunikatu błędu. Następnie porównuje się stan procesu po stronie źródła i odbiorcy: połączenie, uwierzytelnienie, kolejkę oczekujących zmian, pozycję w dzienniku, czas ostatniego potwierdzenia i liczbę błędów. Ważne jest zachowanie logów przed ich rotacją oraz rozróżnienie błędu pierwotnego od kolejnych komunikatów będących jego skutkiem. Samo ponowne uruchomienie usługi może usunąć objaw chwilowy, ale nie wyjaśnia przyczyny ani nie potwierdza kompletności danych.

Przed wznowieniem synchronizacji należy ustalić kierunek przepływu i sprawdzić, czy w czasie awarii wykonywano zapisy po obu stronach. Nie powinno się bez analizy usuwać kolejki, resetować pozycji dziennika ani wymuszać pełnej synchronizacji, ponieważ takie działania mogą pominąć zmiany, nadpisać dane albo ukryć konflikt. Jeżeli brakuje wymaganej historii, odtworzenie repliki z kontrolowanej kopii zapasowej może być bezpieczniejsze niż ręczne przesuwanie punktu startowego. Po naprawie trzeba porównać liczbę i zakres zmian, sprawdzić błędy zastosowania oraz potwierdzić zgodność wybranych danych po obu stronach.

Końcowym etapem jest ustalenie, czy replika może ponownie pełnić swoją funkcję, na przykład obsługiwać odczyty lub przejąć pracę po awarii źródła. Weryfikuje się aktualność synchronizacji, brak zaległej kolejki, poprawność indeksów i ograniczeń oraz zachowanie procesu po ponownym połączeniu. Warto również monitorować opóźnienie, wolne miejsce, stan dzienników, błędy uwierzytelniania i czas przetwarzania. Takie pomiary pozwalają wykryć narastający problem, zanim różnica między wydawcą a subskrybentem stanie się utratą spójności danych.