Replikacja dwustronna

Replikacja dwustronna umożliwia zapis danych zarówno u wydawcy, jak i u subskrybenta, z późniejszym uzgodnieniem zmian.

Na czym polega replikacja dwustronna

Replikacja dwustronna, nazywana także replikacją aktywna–aktywna, pozwala na zapis danych w dwóch współpracujących lokalizacjach. Każda z nich może pełnić jednocześnie rolę źródła zmian oraz odbiorcy zmian pochodzących z drugiej strony. W odróżnieniu od replikacji jednostronnej nie ma jednego, stałego kierunku przepływu wszystkich modyfikacji. Zmiana utworzona w pierwszym systemie jest przekazywana do drugiego, a zmiana wykonana w drugim systemie jest przekazywana z powrotem do pierwszego.

Mechanizm taki nie oznacza prostego kopiowania całej bazy przy każdym zapisie. System replikacji zwykle śledzi operacje dotyczące wierszy, rekordów, obiektów albo bloków danych, a następnie przekazuje je w postaci komunikatów lub wpisów dziennika zmian. Po stronie odbiorcy zmiany są odtwarzane w odpowiedniej kolejności. Szczegóły zależą od konkretnego silnika, ale wspólnym elementem jest konieczność jednoznacznego rozpoznawania źródła operacji, jej identyfikatora oraz miejsca w kolejności przetwarzania.

Uzgadnianie zmian zapisanych w obu lokalizacjach

Największym problemem replikacji dwustronnej jest konflikt, czyli sytuacja, w której obie strony zmodyfikują ten sam obiekt przed odebraniem i zastosowaniem zmiany pochodzącej z drugiej lokalizacji. Konflikt może dotyczyć tego samego pola, całego rekordu albo powiązanych rekordów. Przykładowo, jedna strona może zmienić status zamówienia, a druga w tym samym czasie zmienić jego przypisanego operatora. Jeżeli mechanizm nie ma reguły rozstrzygania, nie da się bezpiecznie ustalić końcowej wartości wyłącznie na podstawie czasu odebrania komunikatu.

Reguły rozwiązywania konfliktów mogą wybierać zmianę z określonego źródła, nowszą wersję według znacznika czasu, wartość o wyższym priorytecie albo wynik specjalnej funkcji scalającej. W niektórych rozwiązaniach konflikt jest odkładany do ręcznej decyzji, zamiast automatycznie nadpisywać jedną z wartości. Sam znacznik czasu nie zawsze jest wystarczający, ponieważ zegary systemowe mogą być niesynchronizowane, a kolejność dotarcia komunikatów może różnić się od kolejności ich utworzenia. Dlatego ważne są także identyfikatory wersji, numery sekwencyjne, informacje o źródle oraz rejestrowanie historii rozstrzygnięć.

Spójność, opóźnienia i ryzyko zapętlenia

Replikacja dwustronna zwykle wymaga zaakceptowania opóźnienia między zapisem a pojawieniem się tej samej zmiany po drugiej stronie. Jest to spójność ostateczna: po ustaniu nowych zmian i przy sprawnym kanale komunikacyjnym oba systemy powinny dojść do zgodnego stanu, ale przez pewien czas mogą prezentować różne dane. Jeżeli aplikacja odczyta rekord wkrótce po zapisie wykonanym w jednej lokalizacji, odczyt z drugiej może jeszcze zwrócić poprzednią wersję.

Mechanizm musi również rozpoznawać, że zmiana zastosowana na drugim węźle pochodzi z replikacji, a nie z nowej operacji użytkownika. Bez takiej informacji ta sama modyfikacja mogłaby zostać odesłana do pierwotnego źródła i ponownie przetworzona, tworząc pętlę replikacyjną. Stosuje się w tym celu identyfikatory transakcji, znaczniki pochodzenia, dzienniki przetworzonych komunikatów oraz ochronę przed wielokrotnym zastosowaniem tej samej operacji. W przypadku przerwy w łączności narastają zaległości, dlatego po wznowieniu pracy konieczne jest wznowienie od właściwego punktu, kontrola brakujących zmian i sprawdzenie, czy nie doszło do rozbieżności.

Diagnostyka rozbieżności i warunki bezpiecznej pracy

Ocena działania replikacji dwustronnej powinna obejmować nie tylko stan procesu replikacyjnego, lecz także zgodność danych na obu końcach. Sprawdza się opóźnienie, liczbę oczekujących zmian, błędy zastosowania operacji, odrzucone komunikaty, konflikty oraz stan kanału komunikacyjnego. Przydatne jest porównywanie sum kontrolnych, liczby rekordów albo wybranych wersji danych, o ile metoda porównania uwzględnia fakt, że oba węzły mogą chwilowo przetwarzać różne operacje.

Przed uruchomieniem takiej topologii trzeba określić, które tabele lub obiekty mogą być modyfikowane z obu stron, jak identyfikowane są rekordy i co dzieje się po konflikcie. Szczególnej uwagi wymagają wartości generowane automatycznie, ponieważ niezależne generowanie identycznych identyfikatorów może doprowadzić do kolizji. Niezbędne są także kopie zapasowe, dzienniki zmian oraz procedura odtwarzania po awarii, ponieważ replikacja nie zastępuje backupu. Replikowane usunięcie może zostać rozpropagowane na oba systemy, a błędna modyfikacja może szybko powielić się w całej topologii. W środowisku komputerowym diagnostyka powinna więc obejmować również stan dysków, pamięci, systemu operacyjnego i połączeń sieciowych, gdyż awaria któregoś z tych elementów może wyglądać jak błąd samego mechanizmu replikacji.