Push- og pull-replikasjonsagentar over ein site-til-site-VPN

Plasseringa til agenten, ikkje plasseringa til dataa, er avgjerda som formar eit SQL Server-abonnement. Maskina som køyrer agenten, opnar tilkoplinga, køyrer under ein bestemt konto og tek skulda når synkroniseringa stoppar. På ein site-til-site-VPN er den skilnaden designet, ikkje ein detalj. Teikn tilkoplingane til agenten før du teiknar nettverket.

Tre roller, ikkje to

Publisher eig artikkeldataa, Distributor eig distribusjonsdatabasen, og Subscriber mottek endringar. Log Reader Agent køyrer hos Distributor for transaksjonsreplikering. Distribution Agent er den som endrar plassering med abonnementstypen, og difor styrer han nettverksdesignet. Rydd opp i desse rollene før du snakkar om VPN-reglar.

Eit push-abonnement køyrer Distribution Agent hos Distributor, og eit pull-abonnement køyrer han hos Subscriber, slik Microsofts abonnementsdokumentasjon seier. Alt i nettsamtalen følgjer av kva maskin det er. Skriv ned fire fakta for kvart abonnement: verten til agenten, prosessidentiteten hans, databaseloggane han brukar og ressursane han må nå. Desse fakta, ikkje ei pil i eit diagram, fortel deg kva retning som må verke.

Push tyder at agenten bur hos Distributor

Med eit push-abonnement opnar Distributor tilkoplinga til Subscriber over VPN-en. Lyttaren, brannmuren og SQL-loggen på abonnentsida må ta imot tilkoplingar som kjem frå den fjerne sida. Tenestekontoen til Distributor treng òg løyve på abonnentdatabasen. Planlegg den innkomande vegen før du opprettar abonnementet, fordi å oppdage han etterpå vanlegvis tyder å gjenskape det.

Snapshotleveransen legg til ein veg som stabil replikering aldri brukar. Viss snapshotet er plassert på ei filutveksling, les Distribution Agent frå den utvekslinga og kontoen til abonnenten må nå same UNC-sti. Ein endringsstraum som går i veker seier ingenting om ein reinitialisering vil verke. Difor høyrer snapshotutvekslinga heime i planen frå starten.

Ikkje les push som einvegstrafikk. Agenten treng svar, stadfestingar og sine eigne autentiseringsutvekslingar. Vegen må vere toveg på tilkoplingsnivå sjølv når data flyttar seg i éi retning.

Pull tyder at agenten bur hos Subscriber

Eit pull-abonnement snur tilkoplinga: Subscriber køyrer Distribution Agent og vender seg til Distributor. Den ordninga passar til ein VPN-policy som tillèt utgåande tilkoplingar frå filialen og blokkerer inngåande. Ho legg òg planleggingsavgjerda i hendene på den som passar filialserveren. Vel han når filialteamet skal eige si eiga synkronisering og merke sine eigne feil.

Tenestekontoen til SQL Server Agent hos abonnenten treng lesetilgang til distribusjonsdatabasen og til snapshotutvekslinga. Den kontoen er identiteten som viser seg i replikeringsfeil, og ein lokal tenestekonto utan domenrettar feilar på eit punkt som ser ut som ein nettverksfeil, men eigenleg er ein legitimasjonsfeil. Kontroller kontoen før du feilsøkjer tunnelen. Å rette loggen er vanlegvis raskare enn å bevise nettverket si uskuld.

Eigarskap følgjer agenten. Vel push når det sentrale teamet skal eige både planen og feila. Uansett kva du vel, skriv det ved sida av abonnementet slik at neste ingeniør veit kvar det skal sjåast først.

Republisering endrar spreiinga, ikkje eigarskapet

Ein abonnent kan konfigurerast til å republisere til fleire abonnentar, slik at éin filialdatabase kan betene fleire lokale forbrukarar utan at kvar av dei dreg over WAN-et. Den midtre databasen har no ein publikasjon og eigne agentar. Han arvar òg løyve, overvaking og ein gjenopprettingsplan som han ikkje hadde før. Den ekstra rolla er prisen for å fjerne gjenteken WAN-levering.

Den dokumenterte rekkjefølgja er viktig: initialiser det innkomande abonnementet før du opprettar publikasjonen nedstraums. Handsame det som eit livssyklussteg med verifisering, ikkje som papirarbeid som hoppast over. Snu du det, får du ei kjede som ser konfigurert ut og leverer ingenting.

Oppgi skrivemodellen eksplisitt. Å replikere eit skrivebeskytta datasett til ein lokal forbrukar er eit anna design enn å ta imot skrivingar på fleire stader, og ei kjede av piler skapar ikkje konfliktløysing. Viss filialen må skrive, er det ei eiga avgjerd med sin eigen topologi. Gjer òg avhengnaden synleg: når republiseringsagenten er nede, er kvar forbrukar under han utdatert.

Bevis plasseringa frå ende til annan

Les abonnementstypen frå distribusjonsdatabasen i staden for å stole på minnet, og kontroller deretter at endringane faktisk kjem:

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 han kan ikkje endrast på staden, så eit avvik tyder å gjenskape abonnementet i staden for å redigere det. Kallet på ventande kommandoar fortel deg om den valde agenten flyttar arbeid eller berre køyrer. Eit abonnement som rapporterer null ventande kommandoar medan abonnenttabellen blir verande tom, er ein annan feil enn eit som rapporterer eit veksande etterslep, og dei to fører til ulike eigarar.

Avslutt med ei reell endring: set inn eller oppdater éi rad hos Publisher, vent på at agenten rapporterer, og les den rada hos Subscriber. Gjer det ein gong til gjennom eit kort VPN-avbrot for å sjå korleis agenten kjem seg. Eit abonnement som overlever den testen, har ei plassering du kan dokumentere og forsvare.