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

Agentens placering, ikke dataens placering, er den beslutning, der former et SQL Server-abonnement. Maskinen, der kører agenten, åbner forbindelsen, kører under en bestemt konto og tager skylden, når synkroniseringen går i stå. På en site-til-site-VPN er den forskel designet, ikke en detalje. Tegn agentens forbindelser, før du tegner netværket.

Tre roller, ikke to

Publisher ejer artikeldataene, Distributor ejer distributionsdatabasen, og Subscriber modtager ændringer. Log Reader Agent kører på Distributor til transaktionsreplikering. Distribution Agent er den, hvis placering ændres med abonnementstypen, og derfor styrer den netværksdesignet. Få de roller på plads, før du taler om VPN-regler.

Et push-abonnement kører Distribution Agent på Distributor, og et pull-abonnement kører den på Subscriber, som Microsofts abonnementsdokumentation angiver. Alt i netværkssamtalen følger af, hvilken maskine det er. Skriv fire fakta ned for hvert abonnement: agentens vært, dens procesidentitet, de databaselogins den bruger, og de ressourcer den skal nå. De fakta, ikke en pil på et diagram, fortæller dig, hvilken retning der skal virke.

Push betyder, at agenten bor på Distributor

Med et push-abonnement åbner Distributor forbindelsen til Subscriber over VPN-forbindelsen. Lytteren, firewallen og SQL-loginet på abonnentsiden skal acceptere forbindelser, der kommer fra den fjerne side. Distributors tjenestekonto skal også have tilladelse på abonnentdatabasen. Planlæg den indgående vej, før du opretter abonnementet, fordi det at opdage den bagefter normalt betyder at genskabe det.

Snapshotlevering tilføjer en vej, som stabil replikering aldrig bruger. Hvis snapshottet er placeret på en filshare, læser Distribution Agent fra den share, og abonnentens konto skal nå den samme UNC-sti. En ændringsstrøm, der løber i uger, siger intet om, hvorvidt en geninitialisering vil virke. Derfor hører snapshotsharen til i planen fra starten.

Læs ikke push som ensrettet trafik. Agenten har brug for svar, bekræftelser og sine egne godkendelsesudvekslinger. Vejen skal være tovejs på forbindelsesniveau, selv når data bevæger sig i én retning.

Pull betyder, at agenten bor på Subscriber

Et pull-abonnement vender forbindelsen: Subscriber kører Distribution Agent og henvender sig til Distributor. Den ordning passer til en VPN-politik, der tillader udgående forbindelser fra filialen og blokerer indgående. Den lægger også planlægningsbeslutningen i hænderne på den, der passer filialserveren. Vælg den, når filialteamet skal eje sin egen synkronisering og bemærke sine egne fejl.

Abonnentens SQL Server Agent-tjenestekonto skal have læseadgang til distributionsdatabasen og til snapshotsharen. Den konto er den identitet, der optræder i replikeringsfejl, og en lokal tjenestekonto uden domænerettigheder fejler på et punkt, der ligner en netværksfejl, men i virkeligheden er en legitimationsfejl. Kontroller kontoen, før du fejlfinder tunnelen. At rette loginet er normalt hurtigere end at bevise netværkets uskyld.

Ejerskab følger agenten. Vælg push, når det centrale team skal eje både plan og fejl. Uanset hvad du vælger, så skriv det ved siden af abonnementet, så den næste ingeniør ved, hvor der skal kigges først.

Genudgivelse ændrer fordelingen, ikke ejerskabet

En abonnent kan konfigureres til at genudgive til flere abonnenter, så én filialdatabase kan betjene flere lokale forbrugere, uden at hver især trækker over WAN-forbindelsen. Den midterste database rummer nu en publikation og sine egne agenter. Den arver også tilladelser, overvågning og en gendannelsesplan, som den ikke havde før. Den ekstra rolle er prisen for at fjerne gentagen WAN-levering.

Den dokumenterede rækkefølge er vigtig: initialisér det indgående abonnement, før du opretter den nedstrøms publikation. Behandl det som et livscyklustrin med verifikation, ikke som papirarbejde, der kan springes over. Vender man det om, får man en kæde, der ser konfigureret ud og leverer intet.

Angiv skrivemodellen eksplicit. At replikere et læse-only-datasæt til en lokal forbruger er et andet design end at acceptere skrivninger på flere lokationer, og en kæde af pile skaber ikke konfliktløsning. Hvis filialen skal skrive, er det en separat beslutning med sin egen topologi. Gør også afhængigheden synlig: når genudgiveren er nede, er hver forbruger under den forældet.

Bevis placeringen fra ende til anden

Læs abonnementstypen fra distributionsdatabasen i stedet for at stole på hukommelsen, og kontrollér derefter, at ændringerne 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 ændres på stedet, så en uoverensstemmelse betyder at genskabe abonnementet i stedet for at redigere det. Kaldet til ventende kommandoer fortæller dig, om den valgte agent flytter arbejde eller blot kører. Et abonnement, der rapporterer nul ventende kommandoer, mens abonnenttabellen forbliver tom, er en anden fejl end et, der rapporterer en voksende efterslæb, og de to fører til forskellige ejere.

Afslut med en reel ændring: indsæt eller opdater én række på Publisher, vent på, at agenten rapporterer, og læs den række på Subscriber. Gør det én gang mere hen over en kort VPN-afbrydelse for at se, hvordan agenten kommer sig. Et abonnement, der overlever den test, har en placering, du kan dokumentere og forsvare.