Push- und Pull-Replikationsagenten über ein Site-zu-Site-VPN

Der Standort des Agents, nicht der Standort der Daten, ist die Entscheidung, die eine SQL Server-Subscription prägt. Die Maschine, die den Agent ausführt, öffnet die Verbindung, läuft unter einem bestimmten Konto und trägt die Schuld, wenn die Synchronisierung stockt. In einem Site-zu-Site-VPN ist dieser Unterschied das Design und kein Detail. Zeichnen Sie die Agentverbindungen, bevor Sie das Netzwerk zeichnen.

Drei Rollen, nicht zwei

Der Publisher besitzt die Artikeldaten, der Distributor besitzt die Verteilungsdatenbank, und der Subscriber empfängt Änderungen. Der Log Reader Agent läuft beim Distributor für die Transaktionsreplikation. Der Distribution Agent ist derjenige, dessen Standort sich mit dem Subscriptionstyp ändert, und deshalb bestimmt er das Netzwerkdesign. Bringen Sie diese Rollen in Ordnung, bevor Sie über VPN-Regeln sprechen.

Eine Push-Subscription führt den Distribution Agent beim Distributor aus, und eine Pull-Subscription führt ihn beim Subscriber aus, wie Microsofts Dokumentation zu Subscriptions festhält. Alles am Netzwerkgespräch folgt daraus, welche Maschine das ist. Notieren Sie vier Fakten für jede Subscription: den Host des Agents, seine Prozessidentität, die Datenbankanmeldungen, die er nutzt, und die Ressourcen, die er erreichen muss. Diese Fakten, nicht ein Diagrammpfeil, sagen Ihnen, welche Richtung funktionieren muss.

Push heißt, der Agent lebt beim Distributor

Bei einer Push-Subscription öffnet der Distributor die Verbindung zum Subscriber über das VPN. Listener, Firewall und SQL-Anmeldung auf der Subscriberseite müssen Verbindungen von der entfernten Seite annehmen. Das Dienstkonto des Distributors braucht außerdem Berechtigung auf der Subscriberdatenbank. Planen Sie diesen eingehenden Pfad, bevor Sie die Subscription erstellen, denn ihn später zu entdecken bedeutet meist, sie neu zu erstellen.

Die Snapshotübermittlung fügt einen Pfad hinzu, den die stationäre Replikation nie nutzt. Wird der Snapshot auf einer Dateifreigabe bereitgestellt, liest der Distribution Agent von dieser Freigabe, und das Konto des Subscribers muss denselben UNC-Pfad erreichen. Ein Änderungsstrom, der wochenlang läuft, sagt nichts darüber, ob eine Neuinitialisierung funktioniert. Darum gehört die Snapshotfreigabe von Anfang an in den Plan.

Lesen Sie Push nicht als Einbahnverkehr. Der Agent braucht Antworten, Bestätigungen und seine eigenen Authentifizierungswechsel. Der Pfad muss auf Verbindungsebene bidirektional sein, auch wenn sich Daten in eine Richtung bewegen.

Pull heißt, der Agent lebt beim Subscriber

Eine Pull-Subscription dreht die Verbindung um: Der Subscriber führt den Distribution Agent aus und wendet sich an den Distributor. Diese Anordnung passt zu einer VPN-Richtlinie, die ausgehende Verbindungen aus der Filiale erlaubt und eingehende blockiert. Sie legt außerdem die Zeitplanentscheidung in die Hände derer, die den Filialserver betreuen. Wählen Sie sie, wenn das Filialteam seine eigene Synchronisierung besitzen und seine eigenen Fehler bemerken soll.

Das Dienstkonto des SQL Server Agent beim Subscriber braucht Lesezugriff auf die Verteilungsdatenbank und auf die Snapshotfreigabe. Dieses Konto ist die Identität, die in Replikationsfehlern erscheint, und ein lokales Dienstkonto ohne Domänenrechte scheitert an einer Stelle, die wie ein Netzwerkfehler aussieht, aber tatsächlich ein Anmeldedatenfehler ist. Prüfen Sie das Konto, bevor Sie den Tunnel debuggen. Die Anmeldung zu reparieren ist meist schneller, als die Unschuld des Netzwerks zu beweisen.

Eigentum folgt dem Agent. Wählen Sie Push, wenn das zentrale Team sowohl Zeitplan als auch Fehler besitzen soll. Was immer Sie wählen, schreiben Sie es neben die Subscription, damit der nächste Ingenieur weiß, wo zuerst nachzusehen ist.

Erneutes Veröffentlichen ändert die Verteilung, nicht das Eigentum

Ein Subscriber kann so konfiguriert werden, dass er an weitere Subscriber erneut veröffentlicht, wodurch eine Filialdatenbank mehrere lokale Konsumenten bedienen kann, ohne dass jeder über das WAN zieht. Die mittlere Datenbank hält nun eine Publikation und eigene Agents. Sie erbt außerdem Berechtigungen, Überwachung und einen Wiederherstellungsplan, die sie vorher nicht hatte. Diese Zusatzrolle ist der Preis für den Wegfall wiederholter WAN-Übermittlung.

Die dokumentierte Reihenfolge ist wichtig: Initialisieren Sie die eingehende Subscription, bevor Sie die nachgelagerte Publikation erstellen. Behandeln Sie das als Lebenszyklusschritt mit Prüfung, nicht als Papierkram, den man überspringt. Die Umkehrung erzeugt eine Kette, die konfiguriert aussieht und nichts liefert.

Nennen Sie das Schreibmodell ausdrücklich. Ein Nur-Lese-Dataset an einen lokalen Konsumenten zu replizieren ist ein anderes Design als Schreibvorgänge an mehreren Standorten anzunehmen, und eine Kette von Pfeilen erzeugt keine Konfliktlösung. Muss die Filiale schreiben, ist das eine eigene Entscheidung mit eigener Topologie. Machen Sie auch die Abhängigkeit sichtbar: Wenn der Wiederveröffentlicherer ausfällt, ist jeder Konsument darunter veraltet.

Beweisen Sie die Platzierung von Ende zu Ende

Lesen Sie den Subscriptionstyp aus der Verteilungsdatenbank, statt dem Gedächtnis zu vertrauen, und prüfen Sie dann, ob Änderungen tatsächlich ankommen:

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

Ein subscription_type von 0 ist Push und 1 ist Pull, und er lässt sich nicht an Ort und Stelle ändern, eine Abweichung bedeutet also, die Subscription neu zu erstellen statt sie zu bearbeiten. Der Aufruf für ausstehende Befehle sagt Ihnen, ob der gewählte Agent Arbeit bewegt oder nur läuft. Eine Subscription, die null ausstehende Befehle meldet, während die Subscribertabelle leer bleibt, ist ein anderer Fehler als eine, die einen wachsenden Rückstand meldet, und beide führen zu verschiedenen Eigentümern.

Schließen Sie mit einer echten Änderung ab: Fügen Sie eine Zeile beim Publisher ein oder aktualisieren Sie sie, warten Sie auf die Meldung des Agents und lesen Sie diese Zeile beim Subscriber. Tun Sie das noch einmal während einer kurzen VPN-Unterbrechung, um zu sehen, wie sich der Agent erholt. Eine Subscription, die diesen Test übersteht, hat eine Platzierung, die Sie dokumentieren und verteidigen können.