Transakcje w replikacji

Transakcje w replikacji są odczytywane z dziennika wydawcy i przekazywane do subskrybentów przez agenta dystrybucji.

Rola dziennika transakcji w replikacji transakcyjnej

W replikacji transakcyjnej programu Microsoft SQL Server źródłem zmian jest dziennik transakcji bazy danych wydawcy. Operacja zatwierdzona na wydawcy, taka jak INSERT, UPDATE lub DELETE, zostawia w dzienniku informacje potrzebne do odtworzenia zmiany. Sam wpis w dzienniku nie jest jednak kompletnym komunikatem przeznaczonym bezpośrednio dla subskrybenta. SQL Server musi rozpoznać transakcję należącą do opublikowanych artykułów, ustalić jej kolejność oraz przygotować polecenia replikacyjne.

Za odczytywanie tych informacji odpowiada Log Reader Agent, czyli agent odczytu dziennika. Agent działa dla publikacji transakcyjnej i przekazuje zmiany do bazy dystrybucyjnej na serwerze dystrybutora. W bazie dystrybucyjnej transakcje są przechowywane do czasu pobrania ich przez agenta dystrybucji. Dzięki temu wydawca nie musi utrzymywać bezpośredniego połączenia z każdym subskrybentem przez cały czas wykonywania zmian.

Od zatwierdzenia transakcji do kolejki dystrybucyjnej

Log Reader Agent zachowuje kolejność transakcji wynikającą z dziennika wydawcy. Ma to znaczenie, gdy kilka operacji odnosi się do tych samych wierszy albo gdy późniejsza zmiana zakłada wykonanie wcześniejszej. Agent nie powinien przekazywać tylko pojedynczych, niezależnych poleceń bez zachowania granic transakcji, ponieważ subskrybent mógłby uzyskać stan pośredni, który nigdy nie został zatwierdzony na wydawcy.

SQL Server zapisuje dla replikowanych transakcji informacje obejmujące między innymi identyfikację publikacji, artykułu, obiektu docelowego oraz wartości wymagane do wykonania operacji. W praktyce do śledzenia położenia zmian używane są numery LSN, czyli Log Sequence Number. LSN pozwala określić miejsce w dzienniku i porównać postęp odczytu dziennika z postępem dystrybucji. Jeżeli Log Reader Agent nie pracuje, dziennik może zawierać nieprzetworzone zmiany potrzebne replikacji, a opóźnienie między wydawcą i subskrybentem zaczyna rosnąć.

Ważne jest rozróżnienie między zatwierdzeniem transakcji lokalnie a jej zastosowaniem u subskrybenta. Udany COMMIT na wydawcy oznacza zakończenie transakcji w bazie źródłowej. Nie oznacza jeszcze, że ta sama zmiana została odebrana i wykonana w bazie subskrybenta. Stan docelowy zależy od pracy kolejnych agentów oraz od dostępności dystrybutora i subskrybenta.

Wykonanie zmian przez agenta dystrybucji

Distribution Agent pobiera z bazy dystrybucyjnej polecenia przygotowane dla konkretnego subskrybenta. Następnie łączy się z bazą subskrybenta i wykonuje te polecenia w odpowiedniej kolejności. Agent może pracować w modelu push, gdy jest uruchamiany po stronie dystrybutora, albo w modelu pull, gdy zadanie pobiera zmiany z dystrybutora. W obu przypadkach logiczny przepływ danych pozostaje taki sam: wydawca zapisuje zmianę, Log Reader Agent przekazuje ją do dystrybucji, a Distribution Agent stosuje ją u subskrybenta.

Jeżeli wykonanie polecenia u subskrybenta zakończy się błędem, agent dystrybucji może zatrzymać dalsze stosowanie zmian zależnych od tego miejsca. Przyczyną może być między innymi brak obiektu, niezgodność schematu, naruszenie ograniczenia integralności, konflikt uprawnień albo niedostępność bazy docelowej. Ponieważ transakcje są uporządkowane, pojedynczy problem może powodować narastanie liczby oczekujących poleceń. Samo ponowne uruchomienie agenta nie usuwa przyczyny błędu; trzeba sprawdzić komunikat, stan schematu i zgodność danych po obu stronach.

Początkowa synchronizacja subskrybenta zwykle korzysta ze snapshotu, który dostarcza strukturę opublikowanych obiektów oraz dane początkowe. Po zakończeniu tej fazy subskrybent może otrzymywać bieżące transakcje z dystrybucji. Snapshot i późniejsza replikacja transakcyjna pełnią różne funkcje: snapshot ustala punkt startowy, natomiast agenci przekazują kolejne zmiany zapisane po tym punkcie.

Rozpoznawanie opóźnień i niespójności

Analiza problemu powinna oddzielnie oceniać trzy odcinki przepływu: zapis transakcji na wydawcy, odczyt dziennika przez Log Reader Agent oraz zastosowanie poleceń przez Distribution Agent. Jeżeli rośnie liczba zmian nieprzetworzonych przez Log Reader Agent, problem znajduje się między dziennikiem wydawcy a bazą dystrybucyjną. Jeżeli dystrybucja otrzymuje nowe polecenia, lecz subskrybent pozostaje w tyle, należy sprawdzić agenta dystrybucji, połączenie, blokady, wydajność bazy docelowej i błędy wykonania.

Przydatne są informacje o czasie ostatniej synchronizacji, liczbie oczekujących poleceń, najstarszym nieprzekazanym LSN oraz stanie agentów replikacji. Nie należy utożsamiać pustego wyniku zapytania na subskrybencie z brakiem replikacji, dopóki nie zostanie potwierdzone, że artykuł obejmuje właściwą tabelę, snapshot został zastosowany, a agent dystrybucji nie zatrzymał się na błędzie. Również zgodność liczby wierszy nie dowodzi pełnej poprawności, ponieważ różne transakcje mogą chwilowo znajdować się na różnych etapach przepływu.

Podczas diagnostyki trzeba zachować ostrożność przy ręcznym modyfikowaniu danych na subskrybencie. Taka zmiana nie pochodzi wtedy z dziennika wydawcy i może zostać nadpisana albo doprowadzić do naruszenia założeń replikacji. Bezpieczniejsza kolejność obejmuje sprawdzenie historii agentów, komunikatów błędów, opóźnienia, stanu publikacji i subskrypcji oraz zgodności schematu. Dopiero na podstawie tych danych można ustalić, czy problem dotyczy odczytu dziennika, kolejki dystrybucyjnej, połączenia czy wykonania konkretnej transakcji.