Push- och pull-replikeringsagenter över en site-till-site-VPN

Agentens placering, inte dataplatsen, är det beslut som formar en SQL Server-prenumeration. Maskinen som kör agenten öppnar anslutningen, arbetar under ett visst konto och tar skulden när synkroniseringen stannar. På en site-till-site-VPN är den skillnaden designen, inte en detalj. Rita agentens anslutningar innan du ritar nätverket.

Tre roller, inte två

Publisher äger artikeldata, Distributor äger distributionsdatabasen och Subscriber tar emot ändringar. Log Reader Agent körs hos Distributor för transaktionell replikering. Distribution Agent är den vars placering ändras med prenumerationstypen, och därför styr den nätverksdesignen. Reda ut dessa roller innan du pratar om VPN-regler.

En push-prenumeration kör Distribution Agent hos Distributor, och en pull-prenumeration kör den hos Subscriber, som Microsofts dokumentation om prenumerationer säger. Allt i nätverkssamtalet följer av vilken maskin det är. Skriv ned fyra fakta för varje prenumeration: agentens värd, dess processidentitet, de databasinloggningar den använder och de resurser den måste nå. Dessa fakta, inte en pil i ett diagram, säger vilken riktning som måste fungera.

push betyder att agenten bor hos Distributor

Med en push-prenumeration öppnar Distributor anslutningen till Subscriber över VPN:en. Lyssnaren, brandväggen och SQL-inloggningen på abonnentsidan måste ta emot anslutningar som kommer från andra sidan. Distributors tjänstekonto behöver också behörighet på abonnentdatabasen. Planera den inkommande vägen innan du skapar prenumerationen, för att upptäcka den efteråt betyder oftast att skapa den på nytt.

Snapshotleveransen lägger till en väg som stabil replikering aldrig använder. Om snapshotten ligger på en filresurs läser Distribution Agent från den resursen och abonnentens konto måste nå samma UNC-sökväg. En ändringsström som pågår i veckor säger ingenting om huruvida en ominitialisering kommer att fungera. Därför hör snapshotresursen hemma i planen från början.

Läs inte push som enkelriktad trafik. Agenten behöver svar, bekräftelser och sina egna autentiseringsutbyten. Vägen måste vara dubbelriktad på anslutningsnivå även när data rör sig i en riktning.

pull betyder att agenten bor hos Subscriber

En pull-prenumeration vänder på anslutningen: Subscriber kör Distribution Agent och vänder sig till Distributor. Det arrangemanget passar en VPN-policy som tillåter utgående anslutningar från filialen och blockerar inkommande. Det lägger också schemabeslutet i händerna på den som sköter filialservern. Välj det när filialteamet ska äga sin egen synkronisering och märka sina egna fel.

Abonnentens SQL Server Agent-tjänstekonto behöver läsbehörighet till distributionsdatabasen och till snapshotresursen. Det kontot är den identitet som dyker upp i replikeringsfel, och ett lokalt tjänstekonto utan domänrättigheter misslyckas i en punkt som ser ut som ett nätverksfel men egentligen är ett autentiseringsfel. Kontrollera kontot innan du felsöker tunneln. Att laga inloggningen är oftast snabbare än att bevisa nätverkets oskuld.

Ägandet följer agenten. Välj push när det centrala teamet ska äga både schemat och felen. Vad du än väljer, skriv det bredvid prenumerationen så att nästa ingenjör vet var den ska titta först.

Återpublicering ändrar spridningen, inte ägandet

En abonnent kan konfigureras att återpublicera till fler abonnenter, vilket låter en filialdatabas betjäna flera lokala konsumenter utan att var och en drar över WAN:et. Den mellersta databasen har nu en publikation och egna agenter. Den ärver också behörigheter, övervakning och en återställningsplan som den inte hade tidigare. Den extra rollen är priset för att ta bort upprepad WAN-leverans.

Den dokumenterade ordningen spelar roll: initiera den inkommande prenumerationen innan du skapar publikationen nedströms. Behandla det som ett livscykelsteg med verifiering, inte som pappersarbete som hoppas över. Att vända på det ger en kedja som ser konfigurerad ut och levererar ingenting.

Ange skrivmodellen uttryckligen. Att replikera en skrivskyddad datauppsättning till en lokal konsument är en annan design än att ta emot skrivningar på flera platser, och en kedja av pilar skapar inte konfliktlösning. Om filialen måste skriva är det ett separat beslut med egen topologi. Gör också beroendet synligt: när återpubliceraren ligger nere är varje konsument under den inaktuell.

Bevisa placeringen från början till slut

Läs prenumerationstypen från distributionsdatabasen i stället för att lita på minnet, och kontrollera sedan att ändringarna verkligen kommer fram:

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 med värdet 0 är push och 1 är pull, och den kan inte ändras på plats, så en avvikelse betyder att prenumerationen skapas på nytt i stället för att redigeras. Anropet för väntande kommandon säger om den valda agenten flyttar arbete eller bara kör. En prenumeration som rapporterar noll väntande kommandon medan abonnenttabellen förblir tom är ett annat fel än en som rapporterar en växande eftersläpning, och de två leder till olika ägare.

Avsluta med en verklig ändring: infoga eller uppdatera en rad hos Publisher, vänta på agentens rapport och läs den raden hos Subscriber. Gör det en gång till under ett kort VPN-avbrott för att se hur agenten återhämtar sig. En prenumeration som överlever det testet har en placering som du kan dokumentera och försvara.