[SQL Server] Réplication : configuration d’un distributeur avec SQL Server 2008 (R2)

Pour chaque type de réplication à mettre en œuvre, la configuration se fait en 3 grandes étapes : configuration du distributeur, configuration de l’éditeur et configuration du ou des abonnés. Ce billet explique comment mettre en œuvre un distributeur via SQL Server Management Studio (SSMS) pour SQL Server 2008 ou SQL Server 2008 R2 (globalement le même mode opératoire que pour les versions 2012 et 2014).


Avant de commencer…

Pour comprendre les différents concepts liés à la réplication, ainsi que l’utilité d’un distributeur, référez-vous aux billets suivants :

• [SQL Server] Replication : présentation générale.
  
• [SQL Server] Réplication : fonctionnement de la réplication de snapshot.
  
• [SQL Server] Réplication : fonctionnement de la réplication transactionnelle.
  
• [SQL Server] Réplication : fonctionnement de la réplication de fusion.
  

Modus operandi de mise-en-place d’un distributeur via SSMS

La première étape sur la configuration de la distribution est identique pour chaque type de réplication. Ainsi, au sein de l’instance du futur éditeur qui accueillera la base de distribution :

• Lancement de l’assistant de configuration du distributeur :
  

  

  Un clic-droit sur Réplication, dans l’explorateur d’objets de SSMS, permet d’accéder au menu contextuel de configuration du distributeur. La fenêtre suivante s’ouvrira en guise d’introduction :
  

  

• Choix de l’instance d’accueil : on choisit celle du futur éditeur (dans notre exemple) :
  

  

• Spécification du dossier de partage des snapshots situé sur le serveur du futur éditeur (toujours dans notre exemple) :
  

  

  On part, bien sûr, du principe que le dossier de partage SQL Replication a déjà été créé et partagé pour les comptes d’exécution du SQL Agent de chaque instance concerné par la réplication.
  

La spécification d’une adresse UNC (Universal Naming Convention) est recommandée afin de permettre sa reconnaissance à travers le réseau par les différents agents de réplication (Merge Agent, notamment).

• Spécification du nom de la base de distribution (par défaut : distribution) et du chemin d’accès de ses fichiers de données et de logs :
  

  

  La base de données sera, bien sûr, stockée sur le même serveur que le futur éditeur.
  

• Sélection des éditeurs (au sens de serveur de publication) destinés à utiliser la base de distribution :
  

  

  On laisse le choix par défaut tel quel, notre futur éditeur étant le seul à utiliser la base de distribution.
  

• Choix du comportement de l’assistant après la configuration :
  

  

  On n’oublie pas de dire à l’assistant de générer le script de configuration du distributeur. Ce script pourrait être utile pour le redéploiement du distributeur en cas de sinistre ou déplacement.
  

• Spécification du chemin d’accès et du nom du script de configuration à générer :
  

  

  Le chemin d’accès choisi est, bien sûr, arbitraire. Il faudra conventionnellement placer le fichier de configuration de la distribution dans un dossier dédié.
  

• Validation et lancement de la configuration du distributeur :
  

  

• Confirmation du résultat :
  

  

  On peut, d’ailleurs, noter la présence de la base de distribution dans la liste des bases systèmes de l’instance :
  

  

  Et les jobs de maintenance de la base de distribution :
  

  

  Tous ces jobs de maintenance de la base de distribution sont créés automatiquement. De plus, certains jobs sont activés et planifiés, d’autres pas. Le tableau ci-dessus dresse un portrait rapide de leur utilité :
  

SQL Agent Job	Utilité	Planification par défaut
Actualisateur d’analyse de réplication pour distribution.	Actualise les informations d’analyse de la réplication pour la base de distribution.	Non planifié. Est lancé automatiquement à chaque démarrage du SQL Agent de l’instance où se trouve la base de distribution.
Nettoyage de la distribution : distribution.	Suppression des transactions répliquées de la base de données de distribution (suivant la période de rétention définie dans les propriétés de la base de distribution). Il rafraîchit également les statistiques de la base de distribution.	Tous les jours, toutes les 10 minutes.
Nettoyage de l’abonnement expiré.	Détecte et retire les abonnements expirés des bases de données publiées.	Tous les jours à 1h du matin.
Nettoyage de l’historique de l’agent : distribution.	Supprime l’historique de l’agent de réplication de la base de données de distribution.	Tous les jours, toutes les 10 minutes.
Réinitialiser les abonnements présentant des erreurs de validation de données.	Réinitialise tous les abonnements qui présentent des erreurs de validation de données. Une validation de données est un processus qui permet de contrôler la consistance entre l’éditeur et l’abonné. Seules les tables sont traitées.	Non planifié. Peut l’être, ou lancé manuellement, à l’occasion.
Vérification des agents de réplication.	Détecte les agents de réplication n’ayant pas d’enregistrement historique actif. Si au moins un agent échoue à reporter son statut à la base de distribution, le job créera une entrée dans l’Event Log de Windows.	Tous les jours, toutes les 10 minutes.

Pour aller plus loin…

Dans de prochains billets, nous traiterons de la mise-en-place des principaux types de réplication.