Agenty replikacji push i pull przez VPN między lokacjami

Położenie agenta, a nie położenie danych, to decyzja, która kształtuje subskrypcję SQL Server. Maszyna uruchamiająca agenta otwiera połączenie, działa na określonym koncie i bierze na siebie winę, gdy synchronizacja się zatrzyma. W sieci VPN między lokacjami ta różnica to projekt, a nie szczegół. Narysuj połączenia agenta, zanim narysujesz sieć.

Trzy role, nie dwie

Publisher posiada dane artykułu, Distributor posiada bazę danych dystrybucji, a Subscriber odbiera zmiany. Log Reader Agent działa na Distributorze w przypadku replikacji transakcyjnej. Distribution Agent to ten, którego położenie zmienia się wraz z typem subskrypcji, i dlatego wyznacza projekt sieci. Uporządkuj te role, zanim zaczniesz mówić o regułach VPN.

Subskrypcja push uruchamia Distribution Agent na Distributorze, a subskrypcja pull uruchamia go na Subscriberze, jak podaje dokumentacja subskrypcji Microsoftu. Wszystko w rozmowie sieciowej wynika z tego, która to maszyna. Zapisz cztery fakty dla każdej subskrypcji: host agenta, jego tożsamość procesu, używane logowania do bazy danych i zasoby, do których musi dotrzeć. Te fakty, a nie strzałka na diagramie, mówią, który kierunek musi działać.

push oznacza, że agent mieszka na Distributorze

Przy subskrypcji push Distributor otwiera połączenie do Subscribera przez VPN. Odbiornik, zapora i logowanie SQL po stronie subskrybenta muszą przyjmować połączenia przychodzące ze zdalnej strony. Konto usługi Distributora potrzebuje też uprawnienia w bazie danych subskrybenta. Zaplanuj tę drogę wejściową, zanim utworzysz subskrypcję, bo odkrycie jej później zwykle oznacza utworzenie jej od nowa.

Dostarczanie migawki dodaje drogę, której stabilna replikacja nigdy nie używa. Jeśli migawka jest umieszczona w udziale plików, Distribution Agent czyta z tego udziału i konto subskrybenta musi dotrzeć do tej samej ścieżki UNC. Strumień zmian działający tygodniami nic nie mówi o tym, czy zadziała ponowna inicjalizacja. Dlatego udział migawki należy do planu od początku.

Nie czytaj push jako ruchu jednokierunkowego. Agent potrzebuje odpowiedzi, potwierdzeń i własnych wymian uwierzytelniania. Droga musi być dwukierunkowa na poziomie połączenia, nawet gdy dane poruszają się w jednym kierunku.

pull oznacza, że agent mieszka na Subscriberze

Subskrypcja pull odwraca połączenie: Subscriber uruchamia Distribution Agent i zwraca się do Distributora. Ten układ pasuje do polityki VPN, która zezwala na połączenia wychodzące z oddziału i blokuje przychodzące. Oddaje też decyzję o harmonogramie w ręce tego, kto opiekuje się serwerem oddziału. Wybierz ją, gdy zespół oddziału ma posiadać własną synchronizację i zauważać własne awarie.

Konto usługi SQL Server Agent subskrybenta potrzebuje dostępu do odczytu bazy danych dystrybucji i udziału migawki. To konto jest tożsamością, która pojawia się w błędach replikacji, a lokalne konto usługi bez uprawnień domeny zawodzi w miejscu, które wygląda jak awaria sieci, ale w rzeczywistości jest awarią poświadczeń. Sprawdź konto, zanim zaczniesz debugować tunel. Naprawienie logowania jest zwykle szybsze niż dowodzenie niewinności sieci.

Własność podąża za agentem. Wybierz push, gdy zespół centralny ma posiadać zarówno harmonogram, jak i awarie. Cokolwiek wybierzesz, zapisz to obok subskrypcji, aby następny inżynier wiedział, gdzie spojrzeć najpierw.

Ponowne publikowanie zmienia rozgałęzienie, nie własność

Subskrybenta można skonfigurować do ponownego publikowania do dalszych subskrybentów, co pozwala jednej bazie oddziału obsłużyć kilku lokalnych odbiorców bez tego, by każdy ciągnął przez WAN. Środkowa baza danych przechowuje teraz publikację i własne agenty. Dziedziczy też uprawnienia, monitorowanie i plan odzyskiwania, których wcześniej nie miała. Ta dodatkowa rola to cena usunięcia powtarzanego dostarczania przez WAN.

Udokumentowana kolejność ma znaczenie: zainicjuj subskrypcję przychodzącą, zanim utworzysz publikację poniżej. Traktuj to jako krok cyklu życia z weryfikacją, a nie jako papierologię do pominięcia. Odwrócenie daje łańcuch, który wygląda na skonfigurowany i niczego nie dostarcza.

Wyraźnie określ model zapisu. Replikowanie zbioru danych tylko do odczytu do lokalnego odbiorcy to inny projekt niż przyjmowanie zapisów w kilku miejscach, a łańcuch strzałek nie tworzy rozwiązywania konfliktów. Jeśli oddział musi zapisywać, to osobna decyzja z własną topologią. Uwidocznij też zależność: gdy republikator nie działa, każdy odbiorca pod nim jest nieaktualny.

Udowodnij rozmieszczenie od początku do końca

Odczytaj typ subskrypcji z bazy danych dystrybucji zamiast ufać pamięci, a następnie sprawdź, czy zmiany naprawdę docierają:

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

subscription_type o wartości 0 to push, a 1 to pull, i nie można go zmienić w miejscu, więc niezgodność oznacza ponowne utworzenie subskrypcji, a nie jej edycję. Wywołanie oczekujących poleceń mówi, czy wybrany agent przenosi pracę, czy tylko działa. Subskrypcja, która zgłasza zero oczekujących poleceń, podczas gdy tabela subskrybenta pozostaje pusta, to inna awaria niż ta, która zgłasza rosnące zaległości, i obie prowadzą do różnych właścicieli.

Zakończ prawdziwą zmianą: wstaw lub zaktualizuj jeden wiersz u Publishera, poczekaj na raport agenta i odczytaj ten wiersz u Subscribera. Zrób to jeszcze raz podczas krótkiej przerwy w VPN, aby zobaczyć, jak agent się podnosi. Subskrypcja, która przeżyje ten test, ma rozmieszczenie, które możesz udokumentować i obronić.