Push- en pull-repliseringsagente oor ’n site-tot-site-VPN

Die agent se ligging, nie die data se ligging nie, is die besluit wat ’n SQL Server-intekening vorm. Die masjien wat die agent laat loop, maak die verbinding oop, werk onder ’n spesifieke rekening en kry die skuld wanneer sinchronisasie vasval. Op ’n site-tot-site-VPN is daardie verskil die ontwerp, nie ’n detail nie. Teken die agentverbindings voordat jy die netwerk teken.

Drie rolle, nie twee nie

Die Publisher besit die artikeldata, die Distributor besit die distribusiedatabasis, en die Subscriber ontvang veranderinge. Die Log Reader Agent loop by die Distributor vir transaksionele replisering. Die Distribution Agent is die een wie se ligging met die intekeningstipe verander, en daarom bepaal dit die netwerkontwerp. Kry daardie rolle reg voordat jy oor VPN-reëls praat.

’n Push-intekening laat die Distribution Agent by die Distributor loop, en ’n pull-intekening laat dit by die Subscriber loop, soos Microsoft se intekeningdokumentasie dit sê. Alles oor die netwerkgesprek volg uit watter masjien dit is. Skryf vier feite vir elke intekening neer: die agent se gasheer, sy prosesidentiteit, die databasistekens wat dit gebruik en die hulpbronne wat dit moet bereik. Daardie feite, nie ’n pyltjie op ’n diagram nie, sê vir jou watter rigting moet werk.

Push beteken die agent woon by die Distributor

Met ’n push-intekening maak die Distributor die verbinding na die Subscriber oor die VPN oop. Die luisteraar, die firewall en die SQL-aanmelding aan die intekenkant moet verbindings van die afgeleë kant aanvaar. Die Distributor se diensrekening het ook toestemming op die intekenaarsdatabasis nodig. Beplan daardie inkomende pad voordat jy die intekening skep, want om dit later te ontdek beteken gewoonlik om dit te herskep.

Die aflewering van ’n momentopname voeg ’n pad by wat bestendige replisering nooit gebruik nie. As die momentopname op ’n lêerdeling geplaas word, lees die Distribution Agent van daardie deling en die intekenaar se rekening moet dieselfde UNC-pad bereik. ’n Veranderingstroom wat weke lank vloei, sê niks oor of ’n herinitialisering sal werk nie. Daarom hoort die momentopname-deling van die begin af in die plan.

Moenie push as eenrigtingverkeer lees nie. Die agent het antwoorde, bevestigings en sy eie verifikasie-uitruilings nodig. Die pad moet op verbindingsvlak tweerigting wees, selfs wanneer data in een rigting beweeg.

Pull beteken die agent woon by die Subscriber

’n Pull-intekening draai die verbinding om: die Subscriber laat die Distribution Agent loop en reik uit na die Distributor. Daardie reëling pas by ’n VPN-beleid wat uitgaande verbindings van die tak toelaat en inkomende verbindings blokkeer. Dit plaas ook die skeduleringsbesluit in die hande van wie ook al na die takbediener kyk. Kies dit wanneer die takspan sy eie sinchronisasie moet besit en sy eie foute moet raaksien.

Die Subscriber se SQL Server Agent-diensrekening het leestoegang tot die distribusiedatabasis en tot die momentopname-deling nodig. Daardie rekening is die identiteit wat in repliseringsfoute verskyn, en ’n plaaslike diensrekening sonder domeinregte misluk op ’n punt wat soos ’n netwerkfout lyk, maar eintlik ’n bewysfout is. Kontroleer die rekening voordat jy die tonnel ontfout. Om die aanmelding reg te maak is gewoonlik vinniger as om die netwerk onskuldig te bewys.

Eienaarskap volg die agent. Kies push wanneer die sentrale span beide die skedule en die foute moet besit. Watter een jy ook al kies, skryf dit langs die intekening neer sodat die volgende ingenieur weet waar om eerste te kyk.

Herpublikasie verander die uitwaaiering, nie die eienaarskap nie

’n Intekenaar kan gekonfigureer word om na verdere intekenare te herpubliseer, wat een takdatabasis in staat stel om verskeie plaaslike verbruikers te bedien sonder dat elkeen oor die WAN trek. Die middelste databasis hou nou ’n publikasie en sy eie agente. Dit erf ook toestemmings, monitering en ’n herstelplan wat dit nie voorheen gehad het nie. Daardie ekstra rol is die prys vir die verwydering van herhaalde WAN-aflewering.

Die gedokumenteerde orde maak saak: initialiseer die inkomende intekening voordat jy die stroomaf-publikasie skep. Behandel dit as ’n lewensiklusstap met ’n verifikasie, nie as papierwerk om oor te slaan nie. Om dit om te keer lewer ’n ketting wat gekonfigureer lyk en niks aflewer nie.

Stel die skryfmodel eksplisiet. Om ’n alleenlees-datastel na ’n plaaslike verbruiker te repliseer is ’n ander ontwerp as om skrywes by verskeie terreine te aanvaar, en ’n ketting pyltjies skep nie konflikoplossing nie. As die tak moet skryf, is dit ’n aparte besluit met sy eie topologie. Maak ook die afhanklikheid sigbaar: wanneer die herpubliseerder af is, is elke verbruiker onder dit verouderd.

Bewys die plasing van begin tot einde

Lees die intekeningstipe uit die distribusiedatabasis in plaas daarvan om jou geheue te vertrou, en kontroleer dan dat veranderinge werklik aankom:

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';

’n subscription_type van 0 is push en 1 is pull, en dit kan nie in plek verander word nie, dus beteken ’n wanverhouding dat die intekening herskep moet word eerder as geredigeer. Die oproep vir hangende opdragte sê vir jou of die gekose agent werk verskuif of bloot loop. ’n Intekening wat nul hangende opdragte rapporteer terwyl die intekenaartabel leeg bly, is ’n ander fout as een wat ’n groeiende agterstand rapporteer, en die twee lei na verskillende eienaars.

Sluit af met ’n werklike verandering: voeg een ry by die Publisher in of werk dit by, wag tot die agent rapporteer en lees daardie ry by die Subscriber. Doen dit nog een keer oor ’n kort VPN-onderbreking om te sien hoe die agent herstel. ’n Intekening wat daardie toets oorleef, het ’n plasing wat jy kan dokumenteer en verdedig.