Diagnostyka replikacji

Diagnostyka replikacji to proces weryfikacji poprawnego działania mechanizmu synchronizacji danych między serwerami.

Zakres diagnostyki mechanizmu replikacji

Diagnostyka replikacji obejmuje sprawdzenie, czy dane są prawidłowo przekazywane między źródłem a odbiorcą oraz czy kolejne zmiany docierają w oczekiwanej kolejności. Analizuje się nie tylko sam fakt połączenia, lecz także stan poszczególnych elementów procesu: źródła danych, kolejki zmian, kanału komunikacyjnego, komponentu zapisującego dane po stronie odbiorczej oraz mechanizmu potwierdzającego wykonanie operacji. Replikacja może działać w jednym kierunku albo w wielu kierunkach, a jej model może zakładać przesyłanie zmian synchronicznie lub z opóźnieniem.

Podczas weryfikacji należy ustalić, jaki zakres danych powinien być kopiowany, jak rozpoznawane są zmiany oraz co system uznaje za poprawne zakończenie operacji. Istotne jest odróżnienie chwilowego opóźnienia od trwałego zatrzymania replikacji. Sam brak identycznego stanu w dwóch lokalizacjach nie zawsze oznacza awarię, ponieważ w replikacji asynchronicznej odbiorca może przez pewien czas przetwarzać starszą wersję danych. Problem występuje wtedy, gdy opóźnienie rośnie, kolejka nie jest opróżniana albo zmiany są odrzucane.

Ślady opóźnienia, błędów i rozbieżności danych

Jednym z podstawowych elementów diagnostyki jest porównanie czasu ostatniej poprawnie przetworzonej zmiany ze znacznikiem najnowszej zmiany dostępnej u źródła. Różnica między tymi wartościami pozwala określić opóźnienie replikacji. W systemach, które posługują się numerami sekwencyjnymi, dziennikami zmian lub identyfikatorami transakcji, sprawdza się również odległość między pozycją źródłową a pozycją potwierdzoną przez odbiorcę. Wzrost tej różnicy wskazuje, że odbiorca nie nadąża z pobieraniem albo wykonywaniem zmian.

Logi powinny być analizowane w kontekście całego łańcucha zdarzeń. Błąd uwierzytelniania, odrzucenie połączenia, przekroczenie limitu czasu, brak miejsca na dane tymczasowe, uszkodzony zapis dziennika lub konflikt klucza mogą zatrzymać przetwarzanie. Należy sprawdzić, czy komunikat pojawia się cyklicznie, czy dotyczy pojedynczej zmiany, oraz czy po nim występuje automatyczne ponowienie. Powtarzające się próby nie świadczą o naprawie, jeżeli ta sama operacja za każdym razem kończy się błędem i blokuje kolejne zmiany.

Rozbieżność danych wymaga rozdzielenia kilku przypadków: brakującego rekordu, rekordu przetworzonego podwójnie, niezgodnej wartości pola oraz różnicy wynikającej z odmiennego momentu odczytu. Porównanie powinno opierać się na jednoznacznym identyfikatorze, wersji zmiany lub innym mechanizmie śledzenia, a nie wyłącznie na liczbie rekordów. Dwie lokalizacje mogą mieć taką samą liczbę rekordów, a mimo to zawierać różne dane.

Połączenie, kolejność zmian i integralność procesu

Weryfikacja warstwy komunikacyjnej obejmuje sprawdzenie rozwiązywania nazw, dostępności właściwego portu, ciągłości połączenia oraz poprawności negocjowanych parametrów zabezpieczenia transmisji, jeśli dany system ich używa. Należy ustalić, czy problem dotyczy całego połączenia, czy tylko określonego kierunku ruchu. Krótkie przerwy sieciowe mogą powodować ponowne zestawianie sesji, ale nie powinny prowadzić do utraty zmian, jeżeli mechanizm posiada trwałą kolejkę i prawidłowo zapisuje punkt wznowienia.

Ważna jest kontrola kolejności. Jeżeli zmiana aktualizująca rekord zostanie zastosowana przed zmianą, która ten rekord tworzy, odbiorca może zgłosić błąd integralności albo zapisać stan niezgodny ze źródłem. Podobne skutki mogą powodować usunięcie wykonane przed aktualizacją lub zastosowanie starszej wersji po nowszej. Diagnostyka powinna więc wykazać, czy system zachowuje kolejność w ramach wymaganej jednostki przetwarzania, czy dopuszcza równoległe wykonywanie zmian i jak rozwiązuje konflikty.

Nie można pomijać zasobów lokalnych. Brak wolnego miejsca, zbyt mała przepustowość zapisu, przeciążenie procesora, ograniczenia pamięci operacyjnej albo zbyt duża liczba oczekujących operacji mogą sprawić, że połączenie pozostaje aktywne, lecz dane nie są skutecznie przetwarzane. W takim przypadku test samej dostępności hosta nie wystarcza. Trzeba zestawić obciążenie zasobów z czasem pobierania zmian, czasem ich zastosowania i długością kolejki.

Bezpieczne potwierdzenie poprawnego działania

Po wykryciu przyczyny należy zweryfikować działanie na kontrolowanym zakresie danych. Przydatne jest prześledzenie jednej nowej zmiany, jednej modyfikacji oraz jednego usunięcia, o ile dany model replikacji dopuszcza te operacje. Dla każdej z nich powinno być możliwe wskazanie momentu utworzenia, przekazania, potwierdzenia i zastosowania po stronie odbiorczej. Taki ślad pozwala odróżnić problem z transportem od problemu z zapisem lub odrzuceniem danych.

Kontrola końcowa powinna obejmować stan kolejki, ostatni potwierdzony punkt synchronizacji, liczbę błędów oraz zgodność wybranych danych według ustalonego identyfikatora. Jeżeli system umożliwia ponowienie pojedynczej operacji, trzeba sprawdzić, czy retry nie tworzy duplikatu i czy jego wykonanie jest idempotentne, czyli wielokrotne zastosowanie tej samej zmiany prowadzi do tego samego poprawnego stanu. Nie należy usuwać kolejki ani resetować punktu synchronizacji bez wcześniejszego ustalenia, jakie zmiany zostaną w ten sposób pominięte.

Wynik diagnostyki powinien jasno wskazywać zakres problemu: opóźnienie, zerwane połączenie, błąd uprawnień, przeciążenie, konflikt zmian, uszkodzenie danych albo nieprawidłową konfigurację procesu. Sama informacja, że „replikacja nie działa”, jest niewystarczająca do dalszej naprawy. Potrzebne są także czasy zdarzeń, identyfikatory błędnych operacji, stan punktu wznowienia i informacja, czy rozbieżność dotyczy wszystkich danych, czy tylko określonego zakresu.