Kompatybilność z replikacją

Kompatybilność z replikacją określa, które obiekty i typy danych mogą być objęte synchronizacją między serwerami.

Zakres obiektów objętych replikacją

Kompatybilność z replikacją oznacza zgodność obiektu, struktury danych i sposobu zapisu z mechanizmem używanym do utrzymywania kopii na innym serwerze. Nie każda tabela, kolekcja, plik ani relacja może być automatycznie synchronizowana. System replikacji musi rozpoznawać typ danych, identyfikować zmiany oraz wiedzieć, w jakiej kolejności zastosować je w kopii docelowej. W praktyce sprawdza się więc nie tylko samą obecność obiektu, lecz także jego zależności, klucze identyfikujące rekordy i reguły modyfikacji.

Podstawowym warunkiem jest istnienie jednoznacznego sposobu wskazania rekordu. W relacyjnych bazach danych najczęściej służy do tego klucz główny, ponieważ pozwala określić, czy odebrana zmiana dotyczy dodania, modyfikacji czy usunięcia konkretnego wiersza. Problemy pojawiają się wtedy, gdy obiekt nie ma stabilnego identyfikatora, zawiera wartości generowane lokalnie na kilku serwerach albo korzysta z zależności, których kopia docelowa nie posiada. Replikacja może wtedy zostać odrzucona, zatrzymana na błędzie albo doprowadzić do rozbieżności danych.

Typy danych i operacji a zgodność kopii

Na kompatybilność wpływa sposób przechowywania poszczególnych typów danych. Proste wartości liczbowe, tekstowe i daty zwykle można przesyłać bez dodatkowej konwersji, o ile oba końce replikacji interpretują je tak samo. Więcej uwagi wymagają dane binarne, duże obiekty, wartości o zmiennej precyzji, identyfikatory generowane automatycznie oraz pola zależne od ustawień regionalnych. Różnica w kodowaniu znaków, strefie czasowej albo sposobie zaokrąglania może spowodować, że technicznie dostarczony rekord będzie miał inną wartość po stronie odbiorcy.

Mechanizm replikacji musi również obsługiwać operacje wykonywane na danych. Dodanie rekordu jest prostsze niż aktualizacja, która wymaga znalezienia właściwego obiektu w kopii. Usunięcie może być niezgodne z konfiguracją, jeżeli rekord jest nadal wskazywany przez zależne obiekty. Osobną kategorię stanowią operacje wykonywane w ramach transakcji. Jeżeli zmiana składa się z kilku powiązanych zapisów, odbiorca powinien zastosować je w tej samej logicznej kolejności albo zachować granicę transakcji. W przeciwnym razie przez pewien czas może powstać stan częściowy, którego nie da się poprawnie odczytać.

Niektóre konfiguracje replikacji obejmują tylko wybrane tabele, kolumny lub zakresy rekordów. Taka selekcja nie jest równoznaczna z pełną kopią bazy. Pominięcie kolumny używanej przez ograniczenie integralności, indeks albo procedurę przetwarzającą dane może uniemożliwić zastosowanie zmian. Dlatego kompatybilność trzeba oceniać dla całego przepływu: źródłowego obiektu, dziennika zmian, transportu, mechanizmu odtwarzania oraz struktury po stronie docelowej.

Integralność, kolejność zmian i konflikty

Zgodna replikacja wymaga zachowania integralności danych. Jeżeli jeden rekord odwołuje się do innego za pomocą klucza obcego, rekord nadrzędny musi istnieć w momencie zastosowania zmiany zależnej albo mechanizm musi zapewniać odpowiednią kolejność operacji. Podobne znaczenie mają ograniczenia unikalności, wymagane wartości, reguły sprawdzające i indeksy wykorzystywane do wyszukiwania zmienianych obiektów. Błąd w jednym z tych elementów może zatrzymać cały strumień zmian, nawet jeśli pozostałe rekordy są prawidłowe.

W replikacji jednokierunkowej konflikt może wystąpić między zmianą wykonaną na źródle a lokalną modyfikacją kopii. W replikacji wielokierunkowej ryzyko jest większe, ponieważ ten sam obiekt może zostać zmieniony równocześnie w kilku miejscach. Samo przesłanie obu wersji nie rozwiązuje problemu. Potrzebna jest określona reguła rozstrzygania, na przykład wybór jednej wersji, odrzucenie późniejszej zmiany albo zapisanie konfliktu do ręcznej analizy. Bez takiej reguły kopie mogą zawierać różne wartości mimo pozornie poprawnego działania transportu.

Istotne jest także rozróżnienie między opóźnieniem a niezgodnością. Opóźnienie oznacza, że zmiana jeszcze nie dotarła lub nie została zastosowana. Niezgodność oznacza, że odbiorca nie może jej zastosować, ponieważ struktura, typ danych, identyfikator albo reguła integralności nie odpowiadają wymaganiom. Diagnostyka powinna obejmować czas ostatniej poprawnie przetworzonej zmiany, liczbę oczekujących operacji, komunikat błędu oraz porównanie struktury obiektu po obu stronach.

Weryfikacja konfiguracji przed uruchomieniem synchronizacji

Przed uruchomieniem replikacji należy ustalić, które obiekty są źródłem zmian, a które mają być odtwarzane w kopii. Następnie porównuje się schematy, nazwy i typy kolumn, klucze główne, ograniczenia, indeksy oraz zależności między tabelami lub innymi obiektami. Warto sprawdzić, czy obie strony używają zgodnego kodowania znaków, formatu czasu i sposobu generowania identyfikatorów. Należy również potwierdzić, że mechanizm ma dostęp do dziennika zmian i że zakres replikacji obejmuje wszystkie wymagane operacje.

Test powinien obejmować pełny cykl: utworzenie danych, modyfikację, usunięcie, zmianę kilku powiązanych obiektów oraz ponowne uruchomienie procesu po przerwie. Po każdej operacji porównuje się wartości po stronie źródłowej i docelowej, a nie tylko stan połączenia. Sam status „połączono” nie dowodzi, że dane są zgodne. Trzeba także sprawdzić zachowanie po błędzie, ponowieniu operacji i pojawieniu się rekordu, którego typ lub zależność nie występuje w kopii.

Jeżeli wykryto niezgodność, nie powinno się usuwać komunikatu błędu ani wymuszać dalszego przetwarzania bez ustalenia przyczyny. Bezpieczniejsza jest analiza konkretnej zmiany, porównanie schematów i sprawdzenie, czy problem dotyczy pojedynczego obiektu, całej kategorii danych czy reguły konfliktów. Dopiero po usunięciu rozbieżności można ponownie wykonać synchronizację i zweryfikować, czy kopia odzyskała spójność.