Replikacja merge

Replikacja scalająca pozwala na niezależne zmiany u wydawcy i subskrybenta, uzgadniane później przez agenta scalającego.

Model działania replikacji scalającej w SQL Server

Replikacja merge, nazywana także replikacją scalającą, jest mechanizmem programu Microsoft SQL Server przeznaczonym do sytuacji, w których zarówno wydawca, jak i subskrybent mogą wykonywać zmiany lokalnie, a następnie synchronizować je z pozostałymi uczestnikami topologii. W odróżnieniu od prostego modelu, w którym tylko jedna strona zapisuje dane, tutaj modyfikacje mogą powstawać po obu stronach połączenia. Synchronizacja nie polega więc wyłącznie na przesłaniu kopii tabeli, lecz na wykryciu zmian, przekazaniu ich między bazami oraz rozstrzygnięciu ewentualnych konfliktów.

W typowej konfiguracji występuje wydawca (Publisher), dystrybutor (Distributor) oraz subskrybent (Subscriber). Za wymianę zmian odpowiada Merge Agent. Agent ten może działać według harmonogramu albo być uruchamiany na żądanie, zależnie od sposobu skonfigurowania subskrypcji. Początkowo subskrybent otrzymuje migawkę inicjalizującą, czyli zestaw danych i obiektów potrzebnych do rozpoczęcia pracy. Późniejsze uruchomienia agenta scalającego przekazują tylko zmiany zarejestrowane od poprzedniej synchronizacji, o ile konfiguracja i stan replikacji pozwalają na użycie takiego przyrostowego przebiegu.

Śledzenie zmian i identyfikacja rekordów

SQL Server musi jednoznacznie rozpoznać, który wiersz został zmieniony, dodany albo usunięty na danym węźle. W artykułach objętych replikacją merge tabele są zwykle wyposażane w kolumnę typu uniqueidentifier z właściwością ROWGUIDCOL oraz domyślną wartością generowaną przez funkcję NEWSEQUENTIALID() albo inną wartość zgodną z wymaganiami konfiguracji. Taki identyfikator pozwala odróżnić ten sam logiczny rekord od innych rekordów, także wtedy, gdy zmiana powstała w oddzielnej bazie subskrybenta.

Replikacja scalająca wykorzystuje również obiekty systemowe i metadane replikacji, między innymi tabele z prefiksem MSmerge_. Przechowują one informacje o publikacjach, artykułach, pokoleniach zmian, subskrypcjach oraz historii synchronizacji. W trakcie pracy SQL Server rejestruje zakresy zmian i ich pochodzenie, aby Merge Agent mógł ustalić, które dane zostały już wymienione, a które nadal oczekują na przesłanie. Usunięcie wiersza również musi zostać odnotowane jako zmiana, ponieważ samo zniknięcie rekordu z jednej bazy nie może być traktowane jako brak informacji przez pozostałe węzły.

Ważnym elementem konfiguracji są filtry artykułów. Pozwalają one ograniczyć zakres danych przekazywanych konkretnemu subskrybentowi, na przykład według wartości przypisanej do oddziału, użytkownika lub regionu. Filtry parametryzowane mogą powodować, że różni subskrybenci otrzymują odmienne podzbiory tej samej publikacji. Zmniejsza to ilość przesyłanych danych, ale zwiększa znaczenie poprawnego zaprojektowania relacji, identyfikatorów i zasad przynależności rekordów do poszczególnych partycji.

Konflikty podczas uzgadniania danych

Konflikt powstaje wtedy, gdy ten sam rekord albo powiązana zmiana zostaną zmodyfikowane niezależnie w więcej niż jednej bazie przed synchronizacją. Przykładem może być aktualizacja tej samej wartości w wydawcy i subskrybencie albo próba dodania danych naruszających te same ograniczenia integralności. Replikacja merge nie zakłada, że zawsze da się automatycznie zachować obie wersje. Musi zastosować ustaloną regułę rozstrzygania konfliktu i zapisać wynik w metadanych oraz historii synchronizacji.

Reguła rozwiązywania konfliktów może zależeć od konfiguracji publikacji i poziomu, na którym konflikt jest oceniany. W praktyce jedna wersja może zostać uznana za zwycięską, a druga odrzucona lub zastąpiona. SQL Server udostępnia informacje o konfliktach za pośrednictwem tabel systemowych i narzędzi monitorujących replikację, dlatego sama informacja, że synchronizacja zakończyła się bez błędu transportowego, nie zawsze oznacza, że wszystkie lokalne wartości zostały zachowane. Przy analizie należy sprawdzić również liczbę konfliktów, ich rodzaj, zwycięską stronę oraz czas wystąpienia.

Konflikty mogą wynikać nie tylko z bezpośredniej edycji jednego wiersza. Ryzyko zwiększają także niespójne filtry, zmiany kluczy obcych, opóźniona synchronizacja, ponowne użycie identyfikatorów oraz usuwanie danych w kilku lokalizacjach. Dlatego projekt topologii powinien określać, które tabele mogą być zmieniane lokalnie, jak często odbywa się synchronizacja i kto analizuje odrzucone modyfikacje. Jeżeli metadane zmian zostaną usunięte zbyt wcześnie albo subskrybent pozostanie niezsynchronizowany przez okres przekraczający wymagany czas przechowywania informacji, może być konieczna ponowna inicjalizacja subskrypcji.

Diagnostyka synchronizacji i wpływ na komputer

Diagnostykę replikacji merge należy rozpocząć od ustalenia, który element topologii nie wykonuje oczekiwanej pracy: SQL Server, SQL Server Agent, dystrybutor, Merge Agent czy sama baza subskrybenta. Warto odczytać historię uruchomień agenta, komunikaty z SQL Server Agent, stan subskrypcji oraz informacje o ostatniej udanej synchronizacji. Błąd połączenia sieciowego, nieprawidłowe dane uwierzytelniające, brak uprawnień do publikacji albo blokada tabeli mogą dawać inny objaw niż rzeczywisty konflikt danych, dlatego nie należy traktować wszystkich komunikatów jako tego samego problemu.

Na komputerze użytkownika można sprawdzić dostępność instancji SQL Server, rozwiązywanie nazwy hosta, możliwość nawiązania połączenia z właściwym portem oraz stan usług odpowiedzialnych za pracę agenta. W przypadku aplikacji korzystającej z lokalnej bazy trzeba dodatkowo potwierdzić, czy program zapisuje dane do tej samej bazy, która została skonfigurowana jako subskrybent. Częstą przyczyną pozornie losowych rozbieżności jest uruchomienie aplikacji na innym środowisku, użycie odmiennego łańcucha połączenia albo synchronizacja innej bazy niż ta, którą operator obserwuje w interfejsie programu.

Naprawa problemu powinna zachować metadane replikacji i rozpocząć się od kopii bezpieczeństwa oraz odczytu historii synchronizacji. Dopiero potem można ocenić, czy wystarczy ponowne uruchomienie agenta, korekta połączenia, usunięcie blokady lub rozstrzygnięcie konfliktu, czy też potrzebna jest ponowna inicjalizacja subskrybenta. Diagnostyka komputera i oprogramowania powinna obejmować zarówno stan usług SQL Server, jak i przepływ danych w aplikacji, ponieważ sprawny proces synchronizacji nie naprawi błędnego zapisu wykonywanego przez program użytkowy.