Problem z replikacją

Problem z replikacją wymaga sprawdzenia stanu agentów oraz zgodności schematu między wydawcą a subskrybentem.

Na czym polega problem z replikacją

Problem z replikacją oznacza, że dane, zmiany konfiguracji albo obiekty opisane po stronie wydawcy nie są prawidłowo przekazywane do subskrybenta. W typowym modelu wydawca rejestruje zmianę, agent lub usługa pośrednicząca odczytuje ją z kolejki, a następnie agent dostarczający zapisuje ją w systemie docelowym. Awaria może wystąpić na każdym z tych etapów. Sam fakt, że proces replikacji jest uruchomiony, nie potwierdza jeszcze, że wszystkie zmiany docierają do subskrybenta i są tam zatwierdzane.

Objawem bywa opóźnienie danych, zatrzymanie synchronizacji, narastająca kolejka zmian albo błąd dotyczący obiektu, którego nie ma w bazie docelowej. Niekiedy replikacja działa dla części tabel lub innych obiektów, a zatrzymuje się dopiero po wystąpieniu pojedynczej niezgodności. Trzeba wtedy odróżnić błąd transportu od błędu wykonania operacji. W pierwszym przypadku agent nie może odczytać lub dostarczyć komunikatu, natomiast w drugim komunikat dociera do subskrybenta, lecz nie może zostać zastosowany.

Agenci, kolejka zmian i połączenie między stronami

Pierwszym etapem diagnostyki jest sprawdzenie stanu wszystkich agentów uczestniczących w replikacji. Należy ustalić, który proces odpowiada za odczyt zmian od wydawcy, który dostarcza je do subskrybenta oraz czy występuje dodatkowy agent obsługujący synchronizację lub rozwiązywanie konfliktów. Ważny jest nie tylko status „uruchomiony”, ale również czas ostatniego poprawnego działania, liczba błędów, ponowień i oczekujących komunikatów. Agent może pozostawać aktywny jako proces systemowy, a jednocześnie nie wykonywać postępu z powodu blokady, błędnych uprawnień albo problemu z połączeniem.

Sprawdza się również możliwość zestawienia połączenia między wydawcą, agentami i subskrybentem. Weryfikacji wymagają nazwy hostów, adresy, porty, rozwiązywanie nazw, reguły zapory oraz poprawność poświadczeń używanych przez usługę. Jeżeli agent działa na innym komputerze, trzeba uwzględnić także dostęp sieciowy z perspektywy tego konkretnego hosta, a nie tylko z komputera administratora. Przydatne jest porównanie czasu ostatniego odebranego i zatwierdzonego komunikatu. Jeżeli liczba zmian po stronie wydawcy rośnie, lecz po stronie subskrybenta nie przybywają zastosowane operacje, problem leży w dostarczaniu albo przetwarzaniu kolejki.

Zgodność schematu wydawcy i subskrybenta

Replikacja może zatrzymać się po zmianie struktury danych. Wydawca i subskrybent muszą mieć zgodne obiekty wymagane przez konkretny mechanizm: tabele, kolumny, typy danych, klucze, ograniczenia oraz elementy potrzebne do jednoznacznego identyfikowania rekordów. Niezgodność może powstać po ręcznej modyfikacji jednej ze stron, po częściowo wykonanej migracji albo po odtworzeniu subskrybenta z nieaktualnej kopii. Szczególne znaczenie ma kolejność zmian schematu. Operacja zapisana na wydawcy nie zostanie zastosowana, jeżeli docelowy obiekt nie istnieje lub nie przyjmuje danych w wymaganym formacie.

Porównanie powinno obejmować nie tylko nazwy tabel, lecz także definicje kolumn i ich właściwości. Kolumna obowiązkowa po stronie subskrybenta, której nie dostarcza wydawca, może powodować odrzucenie operacji. Z kolei różny typ danych, rozmiar pola albo sposób generowania wartości klucza może prowadzić do błędu dopiero dla określonego rekordu. Trzeba ustalić, czy zmiana schematu była obsługiwana przez mechanizm replikacji, czy wymagała osobnego wdrożenia po obu stronach. Po usunięciu przyczyny należy sprawdzić komunikat, który zatrzymał proces, oraz zweryfikować, czy zaległe zmiany zostały zastosowane bez pominięcia danych.

Bezpieczne przywracanie spójności danych

Naprawa problemu z replikacją powinna rozpocząć się od zabezpieczenia informacji o stanie kolejki, ostatnim poprawnym komunikacie i treści błędu. Nie należy od razu usuwać kolejki ani wymuszać ponownej inicjalizacji, ponieważ takie działania mogą utrudnić ustalenie przyczyny i doprowadzić do pominięcia zmian. Po potwierdzeniu poprawności połączeń oraz zgodności schematu można ponownie uruchomić właściwego agenta i obserwować, czy liczba oczekujących operacji maleje. Jeżeli wystąpił konflikt danych, trzeba ustalić, która wersja rekordu jest źródłem prawdy zgodnie z konfiguracją danego rozwiązania.

W przypadku diagnostyki komputera, na którym uruchomiono narzędzia administracyjne lub lokalny komponent replikacji, analizuje się logi systemowe, stan usług, dostępne miejsce na dysku, działanie sieci oraz uprawnienia konta usługi. Te elementy nie zastępują kontroli konfiguracji po stronie wydawcy i subskrybenta, ale pozwalają wykryć lokalną przyczynę zatrzymania procesu. Po przywróceniu działania warto potwierdzić synchronizację na podstawie konkretnych identyfikatorów lub znaczników czasu, a nie wyłącznie na podstawie informacji, że agent ma status aktywny.