Merge Agent

Merge Agent to komponent replikacji scalającej, uzgadniający zmiany wprowadzone niezależnie u wydawcy i subskrybenta.

Rola Merge Agent w replikacji scalającej SQL Server

Merge Agent jest składnikiem replikacji scalającej w Microsoft SQL Server. Jego zadaniem jest okresowe synchronizowanie danych pomiędzy bazą wydawcy (Publisher) a bazą subskrybenta (Subscriber). W przeciwieństwie do replikacji, w której zmiany płyną wyłącznie w jednym kierunku, replikacja scalająca zakłada, że modyfikacje mogą powstawać zarówno po stronie wydawcy, jak i subskrybenta. Agent pobiera zmiany z obu stron, przekazuje je do drugiej bazy i uczestniczy w rozstrzyganiu sytuacji, gdy te same dane zostały zmienione niezależnie.

Proces Merge Agent może być uruchamiany przez SQL Server Agent jako zadanie, przez aplikację korzystającą z interfejsu replikacji albo z użyciem narzędzi administracyjnych SQL Server. W typowej konfiguracji agent działa dla konkretnej subskrypcji i konkretnej publikacji. Podczas synchronizacji odczytuje metadane replikacji, identyfikuje zmiany oczekujące na przekazanie, wykonuje operacje po stronie docelowej i zapisuje informacje potrzebne do ustalenia, które generacje danych zostały już zsynchronizowane.

Śledzenie zmian i wymiana danych między węzłami

Replikacja scalająca nie porównuje przy każdej synchronizacji całej zawartości wszystkich tabel. SQL Server wykorzystuje wewnętrzne metadane, które opisują zmienione wiersze, generacje zmian oraz historię synchronizacji. W bazach uczestniczących w replikacji scalającej można spotkać między innymi tabele systemowe o nazwach MSmerge_contents, MSmerge_tombstone i MSmerge_genhistory. MSmerge_contents przechowuje informacje związane ze zmianami w opublikowanych tabelach, MSmerge_tombstone służy do rejestrowania usunięć, a MSmerge_genhistory opisuje generacje zmian używane podczas uzgadniania stanu replik.

Podczas synchronizacji agent ustala zakres zmian, które powinny zostać przesłane w danym kierunku. Modyfikacje wykonane u subskrybenta są najpierw przekazywane do wydawcy, a następnie zmiany pochodzące od wydawcy lub innych subskrybentów są pobierane do bazy lokalnej. Kolejność i zakres operacji zależą od topologii, konfiguracji subskrypcji, filtrów artykułów oraz informacji o poprzednich synchronizacjach. Usunięcie wiersza również musi być odnotowane w metadanych, ponieważ sam brak rekordu nie pozwalałby odróżnić usunięcia od sytuacji, w której dany wiersz nigdy nie został dostarczony do konkretnego subskrybenta.

Konflikty, rozwiązywanie zmian i integralność synchronizacji

Konflikt pojawia się wtedy, gdy ten sam logiczny wiersz albo powiązany zakres danych został zmieniony niezależnie w więcej niż jednym miejscu przed zakończeniem synchronizacji. Przykładem może być aktualizacja tej samej wartości u wydawcy i u subskrybenta. Merge Agent wykrywa taką sytuację na podstawie metadanych zmian i przekazuje ją do skonfigurowanego mechanizmu rozwiązywania konfliktów. Wynik może zależeć od przypisanego priorytetu, reguł resolvera albo od decyzji zapisanej w konfiguracji publikacji.

Ważnym elementem diagnostyki jest rozróżnienie konfliktu danych od błędu transportu lub błędu wykonania polecenia. Konflikt może zakończyć synchronizację ostrzeżeniem, ale nie musi oznaczać awarii połączenia. Z kolei problemy z uwierzytelnianiem, uprawnieniami, dostępnością instancji, blokadami, niezgodnością schematu lub naruszeniem ograniczenia integralności mogą zatrzymać synchronizację niezależnie od mechanizmu rozstrzygania konfliktów. Informacje o przebiegu pracy agenta należy analizować razem z historią zadań replikacji i komunikatami SQL Server, ponieważ sam komunikat o nieudanej synchronizacji często nie wskazuje jeszcze, czy przyczyną była konkretna tabela, konflikt czy problem infrastrukturalny.

Diagnostyka pracy Merge Agent

Analizę problemu należy rozpocząć od ustalenia, której publikacji i której subskrypcji dotyczy błąd oraz w jakim kierunku miała przebiegać synchronizacja. Następnie warto sprawdzić historię uruchomień Merge Agent, czas rozpoczęcia i zakończenia, liczbę przetworzonych zmian oraz pełny tekst komunikatu błędu. Istotne są także informacje o czasie ostatniej poprawnej synchronizacji. Długi odstęp między synchronizacjami może zwiększyć liczbę zaległych zmian i prawdopodobieństwo konfliktów, ale sam w sobie nie dowodzi uszkodzenia danych.

W praktyce sprawdza się dostępność wydawcy, dystrybutora i subskrybenta, stan połączenia, uprawnienia kont używanych przez agenta oraz zgodność schematu opublikowanych tabel. Należy również zweryfikować, czy filtry publikacji nie powodują pominięcia danych wymaganych przez aplikację i czy metadane replikacji nie zbliżają się do okresu przechowywania skonfigurowanego dla publikacji. Przy utracie lub wycofaniu subskrypcji ponowne wykonanie synchronizacji bez rozpoznania stanu metadanych może pogłębić problem, dlatego operacje takie jak ponowna inicjalizacja powinny wynikać z potwierdzonej diagnozy. Analiza Merge Agent wymaga dostępu do konkretnej konfiguracji oraz administracyjnych danych środowiska SQL Server.