Push- og pull-replikasjonsagenter over en site-til-site-VPN

Plasseringen til agenten, ikke plasseringen til dataene, er beslutningen som former et SQL Server-abonnement. Maskinen som kjører agenten, åpner tilkoblingen, kjører under en bestemt konto og tar skylden når synkroniseringen stopper. På en site-til-site-VPN er den forskjellen designet, ikke en detalj. Tegn agentens tilkoblinger før du tegner nettverket.

Tre roller, ikke to

Publisher eier artikkeldataene, Distributor eier distribusjonsdatabasen, og Subscriber mottar endringer. Log Reader Agent kjører hos Distributor for transaksjonsreplikering. Distribution Agent er den som endrer plassering med abonnementstypen, og derfor styrer den nettverksdesignet. Rydd opp i disse rollene før du snakker om VPN-regler.

Et push-abonnement kjører Distribution Agent hos Distributor, og et pull-abonnement kjører den hos Subscriber, slik Microsofts abonnementsdokumentasjon sier. Alt i nettsamtalen følger av hvilken maskin det er. Skriv ned fire fakta for hvert abonnement: agentens vert, dens prosessidentitet, databaseloginene den bruker og ressursene den må nå. Disse fakta, ikke en pil i et diagram, forteller deg hvilken retning som må virke.

Push betyr at agenten bor hos Distributor

Med et push-abonnement åpner Distributor tilkoblingen til Subscriber over VPN-en. Lytteren, brannmuren og SQL-loginen på abonnentsiden må ta imot tilkoblinger som kommer fra den fjerne siden. Tjenestekontoen til Distributor trenger også tillatelse på abonnentdatabasen. Planlegg den innkommende veien før du oppretter abonnementet, fordi å oppdage den etterpå vanligvis betyr å gjenskape det.

Snapshotleveringen legger til en vei som stabil replikering aldri bruker. Hvis snapshotet er plassert på en filutveksling, leser Distribution Agent fra den utvekslingen og kontoen til abonnenten må nå samme UNC-sti. En endringsstrøm som går i uker sier ingenting om hvorvidt en reinitialisering vil virke. Derfor hører snapshotutvekslingen hjemme i planen fra starten.

Ikke les push som ensrettet trafikk. Agenten trenger svar, bekreftelser og sine egne autentiseringsutvekslinger. Veien må være toveis på tilkoblingsnivå selv når data beveger seg i én retning.

Pull betyr at agenten bor hos Subscriber

Et pull-abonnement snur tilkoblingen: Subscriber kjører Distribution Agent og henvender seg til Distributor. Den ordningen passer til en VPN-policy som tillater utgående tilkoblinger fra filialen og blokkerer innkommende. Den legger også planleggingsbeslutningen i hendene på den som passer filialserveren. Velg den når filialteamet skal eie sin egen synkronisering og merke sine egne feil.

Tjenestekontoen til SQL Server Agent hos abonnenten trenger lesetilgang til distribusjonsdatabasen og til snapshotutvekslingen. Den kontoen er identiteten som vises i replikeringsfeil, og en lokal tjenestekonto uten domenrettigheter feiler på et punkt som ser ut som en nettverksfeil, men egentlig er en legitimasjonsfeil. Kontroller kontoen før du feilsøker tunnelen. Å rette loginen er vanligvis raskere enn å bevise nettverkets uskyld.

Eierskap følger agenten. Velg push når det sentrale teamet skal eie både planen og feilene. Uansett hva du velger, skriv det ved siden av abonnementet slik at neste ingeniør vet hvor det skal ses først.

Republisering endrer spredningen, ikke eierskapet

En abonnent kan konfigureres til å republisere til flere abonnenter, slik at én filialdatabase kan betjene flere lokale forbrukere uten at hver av dem drar over WAN-et. Den midterste databasen har nå en publikasjon og egne agenter. Den arver også tillatelser, overvåking og en gjenopprettingsplan som den ikke hadde før. Den ekstra rollen er prisen for å fjerne gjentatt WAN-levering.

Den dokumenterte rekkefølgen er viktig: initialiser det innkommende abonnementet før du oppretter publikasjonen nedstrøms. Behandle det som et livssyklusstrinn med verifisering, ikke som papirarbeid som hoppes over. Reverserer du det, får du en kjede som ser konfigurert ut og leverer ingenting.

Oppgi skrivemodellen eksplisitt. Å replikere et skrivebeskyttet datasett til en lokal forbruker er et annet design enn å akseptere skrivinger på flere steder, og en kjede av piler skaper ikke konfliktløsning. Hvis filialen må skrive, er det en egen beslutning med sin egen topologi. Gjør også avhengigheten synlig: når republiseringsagenten er nede, er hver forbruker under den utdatert.

Bevis plasseringen fra ende til annen

Les abonnementstypen fra distribusjonsdatabasen i stedet for å stole på hukommelsen, og kontroller deretter at endringene faktisk ankommer:

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 på 0 er push og 1 er pull, og den kan ikke endres på stedet, så et avvik betyr å gjenskape abonnementet i stedet for å redigere det. Kallet på ventende kommandoer forteller deg om den valgte agenten flytter arbeid eller bare kjører. Et abonnement som rapporterer null ventende kommandoer mens abonnenttabellen forblir tom, er en annen feil enn et som rapporterer en voksende etterslep, og de to fører til forskjellige eiere.

Avslutt med en reell endring: sett inn eller oppdater én rad hos Publisher, vent på at agenten rapporterer, og les den raden hos Subscriber. Gjør det én gang til gjennom en kort VPN-avbrudd for å se hvordan agenten kommer seg. Et abonnement som overlever den testen, har en plassering du kan dokumentere og forsvare.