Agents de réplication push et pull sur un VPN de site à site

L’emplacement de l’agent, et non celui des données, est la décision qui façonne un abonnement SQL Server. La machine qui exécute l’agent ouvre la connexion, s’exécute sous un compte précis et porte le blâme quand la synchronisation se bloque. Sur un VPN de site à site, cette différence est la conception, pas un détail. Dessinez les connexions de l’agent avant de dessiner le réseau.

Trois rôles, pas deux

Le Publisher possède les données de l’article, le Distributor possède la base de données de distribution et le Subscriber reçoit les modifications. Le Log Reader Agent s’exécute sur le Distributor pour la réplication transactionnelle. Le Distribution Agent est celui dont l’emplacement change avec le type d’abonnement, et c’est pourquoi il pilote la conception du réseau. Clarifiez ces rôles avant de parler de règles VPN.

Un abonnement push exécute le Distribution Agent sur le Distributor, et un abonnement pull l’exécute sur le Subscriber, comme l’indique la documentation sur les abonnements de Microsoft. Tout le dialogue réseau découle de la machine concernée. Notez quatre faits pour chaque abonnement : l’hôte de l’agent, son identité de processus, les connexions de base de données qu’il utilise et les ressources qu’il doit atteindre. Ces faits, et non une flèche du schéma, vous disent quelle direction doit fonctionner.

Push signifie que l’agent vit sur le Distributor

Avec un abonnement push, le Distributor ouvre la connexion vers le Subscriber à travers le VPN. L’écouteur, le pare-feu et la connexion SQL côté abonné doivent accepter les connexions venant du côté distant. Le compte de service du Distributor a aussi besoin d’une autorisation sur la base de données de l’abonné. Planifiez ce chemin entrant avant de créer l’abonnement, car le découvrir ensuite signifie généralement le recréer.

La livraison d’un instantané ajoute un chemin que la réplication stable n’emprunte jamais. Si l’instantané est déposé sur un partage de fichiers, le Distribution Agent lit depuis ce partage et le compte de l’abonné doit atteindre le même chemin UNC. Un flux de modifications qui dure des semaines ne dit rien sur la réussite d’une réinitialisation. C’est pourquoi le partage d’instantané fait partie du plan dès le départ.

Ne lisez pas push comme un trafic à sens unique. L’agent a besoin de réponses, d’accusés et de ses propres échanges d’authentification. Le chemin doit être bidirectionnel au niveau de la connexion même quand les données circulent dans un seul sens.

Pull signifie que l’agent vit sur le Subscriber

Un abonnement pull inverse la connexion : le Subscriber exécute le Distribution Agent et sollicite le Distributor. Cette disposition convient à une politique VPN qui autorise les connexions sortantes depuis l’agence et bloque les entrantes. Elle place aussi la décision de planification entre les mains de qui s’occupe du serveur de l’agence. Choisissez-la quand l’équipe de l’agence doit posséder sa propre synchronisation et remarquer ses propres échecs.

Le compte de service SQL Server Agent de l’abonné a besoin d’un accès en lecture à la base de données de distribution et au partage d’instantané. Ce compte est l’identité qui apparaît dans les erreurs de réplication, et un compte de service local sans droits de domaine échoue à un endroit qui ressemble à une panne réseau mais qui est en réalité une panne d’identifiants. Vérifiez le compte avant de déboguer le tunnel. Corriger la connexion est généralement plus rapide que de prouver l’innocence du réseau.

La propriété suit l’agent. Choisissez push quand l’équipe centrale doit posséder à la fois la planification et les échecs. Quel que soit votre choix, écrivez-le à côté de l’abonnement pour que l’ingénieur suivant sache où regarder en premier.

La republication change la diffusion, pas la propriété

Un abonné peut être configuré pour republier vers d’autres abonnés, ce qui permet à une base de données d’agence de servir plusieurs consommateurs locaux sans que chacun tire à travers le WAN. La base intermédiaire contient désormais une publication et ses propres agents. Elle hérite aussi d’autorisations, d’une surveillance et d’un plan de récupération qu’elle n’avait pas auparavant. Ce rôle supplémentaire est le prix de la suppression de la livraison WAN répétée.

L’ordre documenté compte : initialisez l’abonnement entrant avant de créer la publication en aval. Traitez cela comme une étape du cycle de vie avec vérification, non comme de la paperasse à sauter. L’inverser produit une chaîne qui semble configurée et ne livre rien.

Énoncez explicitement le modèle d’écriture. Répliquer un jeu de données en lecture seule vers un consommateur local est une conception différente de l’acceptation d’écritures sur plusieurs sites, et une chaîne de flèches ne crée pas de résolution des conflits. Si l’agence doit écrire, c’est une décision distincte avec sa propre topologie. Rendez aussi la dépendance visible : quand le republieur est arrêté, chaque consommateur en dessous est périmé.

Prouvez le placement de bout en bout

Lisez le type d’abonnement depuis la base de données de distribution au lieu de faire confiance à la mémoire, puis vérifiez que les modifications arrivent réellement :

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

Un subscription_type de 0 est push et 1 est pull, et il ne peut pas être changé sur place, donc une divergence signifie recréer l’abonnement plutôt que le modifier. L’appel des commandes en attente vous dit si l’agent choisi déplace du travail ou ne fait que tourner. Un abonnement qui signale zéro commande en attente alors que la table de l’abonné reste vide est une panne différente de celui qui signale un arriéré croissant, et les deux mènent à des propriétaires différents.

Terminez par une vraie modification : insérez ou mettez à jour une ligne sur le Publisher, attendez le rapport de l’agent et lisez cette ligne sur le Subscriber. Refaites-le pendant une brève interruption du VPN pour voir comment l’agent récupère. Un abonnement qui survit à ce test a un placement que vous pouvez documenter et défendre.