Push- en pull-replicatieagents over een site-naar-site-VPN

De locatie van de agent, niet de locatie van de gegevens, is de beslissing die een SQL Server-abonnement vormt. De machine die de agent draait, opent de verbinding, werkt onder een bepaald account en draagt de schuld als de synchronisatie vastloopt. Op een site-naar-site-VPN is dat verschil het ontwerp, geen detail. Teken de agentverbindingen voordat u het netwerk tekent.

Drie rollen, niet twee

De Publisher bezit de artikelgegevens, de Distributor bezit de distributiedatabase en de Subscriber ontvangt wijzigingen. De Log Reader Agent draait bij de Distributor voor transactionele replicatie. De Distribution Agent is degene wiens locatie met het abonnementstype verandert, en daarom bepaalt hij het netwerkontwerp. Zet die rollen recht voordat u over VPN-regels praat.

Een push-abonnement draait de Distribution Agent bij de Distributor, en een pull-abonnement draait hem bij de Subscriber, zoals de abonnementsdocumentatie van Microsoft stelt. Alles in het netwerkgesprek volgt uit welke machine dat is. Noteer vier feiten per abonnement: de host van de agent, zijn procesidentiteit, de databaseaanmeldingen die hij gebruikt en de resources die hij moet bereiken. Die feiten, niet een pijl in een diagram, vertellen u welke richting moet werken.

Push betekent dat de agent bij de Distributor woont

Bij een push-abonnement opent de Distributor de verbinding naar de Subscriber over de VPN. De listener, de firewall en de SQL-aanmelding aan abonnentzijde moeten verbindingen van de externe kant accepteren. Het serviceaccount van de Distributor heeft ook toestemming nodig op de abonnentdatabase. Plan dat inkomende pad voordat u het abonnement maakt, want het later ontdekken betekent meestal opnieuw maken.

De levering van een snapshot voegt een pad toe dat stabiele replicatie nooit gebruikt. Als de snapshot op een bestandsshare staat, leest de Distribution Agent van die share en moet het account van de abonnee hetzelfde UNC-pad bereiken. Een wijzigingenstroom die weken loopt, zegt niets over of een herinitialisatie werkt. Daarom hoort de snapshotshare vanaf het begin in het plan.

Lees push niet als eenrichtingsverkeer. De agent heeft antwoorden, bevestigingen en zijn eigen authenticatie-uitwisselingen nodig. Het pad moet op verbindingsniveau bidirectioneel zijn, ook wanneer gegevens zich in één richting verplaatsen.

Pull betekent dat de agent bij de Subscriber woont

Een pull-abonnement draait de verbinding om: de Subscriber draait de Distribution Agent en benadert de Distributor. Die opzet past bij een VPN-beleid dat uitgaande verbindingen vanaf de vestiging toestaat en inkomende blokkeert. Het legt ook de planningsbeslissing in handen van wie de vestigingsserver beheert. Kies het wanneer het vestigingsteam zijn eigen synchronisatie moet bezitten en zijn eigen fouten moet opmerken.

Het SQL Server Agent-serviceaccount van de abonnee heeft leestoegang nodig tot de distributiedatabase en tot de snapshotshare. Dat account is de identiteit die in replicatiefouten verschijnt, en een lokaal serviceaccount zonder domeinrechten faalt op een punt dat op een netwerkstoring lijkt maar in werkelijkheid een aanmeldingsstoring is. Controleer het account voordat u de tunnel debugt. De aanmelding repareren is meestal sneller dan de onschuld van het netwerk bewijzen.

Eigendom volgt de agent. Kies push wanneer het centrale team zowel de planning als de fouten moet bezitten. Wat u ook kiest, schrijf het naast het abonnement zodat de volgende engineer weet waar eerst te kijken.

Herkpublicatie verandert de spreiding, niet het eigendom

Een abonnee kan zo worden geconfigureerd dat hij opnieuw publiceert naar verdere abonnees, waardoor één vestigingsdatabase meerdere lokale consumenten kan bedienen zonder dat elk over de WAN trekt. De middelste database bevat nu een publicatie en eigen agents. Hij erft ook machtigingen, monitoring en een herstelplan die hij voorheen niet had. Die extra rol is de prijs voor het verwijderen van herhaalde WAN-levering.

De gedocumenteerde volgorde is belangrijk: initialiseer het inkomende abonnement voordat u de stroomafwaartse publicatie maakt. Behandel dat als een levenscyclusstap met verificatie, niet als papierwerk om over te slaan. Omgekeerd levert het een keten op die geconfigureerd lijkt en niets levert.

Noem het schrijfmodel expliciet. Een alleen-lezen dataset naar een lokale consument repliceren is een ander ontwerp dan schrijfacties op meerdere locaties accepteren, en een keten van pijlen creëert geen conflictoplossing. Als de vestiging moet schrijven, is dat een aparte beslissing met een eigen topologie. Maak ook de afhankelijkheid zichtbaar: als de herpubliceerder uitvalt, is elke consument eronder verouderd.

Bewijs de plaatsing van begin tot eind

Lees het abonnementstype uit de distributiedatabase in plaats van op het geheugen te vertrouwen, en controleer dan of wijzigingen echt aankomen:

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

Een subscription_type van 0 is push en 1 is pull, en hij kan niet ter plaatse worden gewijzigd, dus een afwijking betekent het abonnement opnieuw maken in plaats van het te bewerken. De aanroep van wachtende opdrachten vertelt u of de gekozen agent werk verplaatst of alleen draait. Een abonnement dat nul wachtende opdrachten meldt terwijl de abonneetabel leeg blijft, is een andere fout dan een dat een groeiende achterstand meldt, en beide leiden tot verschillende eigenaren.

Sluit af met een echte wijziging: voeg één rij toe bij de Publisher of werk die bij, wacht op het rapport van de agent en lees die rij bij de Subscriber. Doe dat nog eens tijdens een korte VPN-onderbreking om te zien hoe de agent herstelt. Een abonnement dat die test overleeft, heeft een plaatsing die u kunt documenteren en verdedigen.