Blog

Réplication – Initialisation d’un abonné par sauvegarde/restauration


Dans cet article, nous allons créer une publication transactionnelle et lancer l’initialisation d’un abonné par sauvegarde/restauration à partir d’un autre abonné utilisé comme référence. Cette méthode est appropriée dans les cas suivants :

  • N bases abonnées, strictement identiques au niveau structure
  • Personnalisations importantes des bases abonnées (ex : index)

Attention : cette méthode implique de suspendre toutes les synchronisations au même moment pendant toute la durée de l’initialisation d’un abonné. L’objectif étant de partir d’une base abonnée susceptible de contenir des personnalisations importantes (ex : index, vues indexées) et d’industrialiser la création/initialisation d’autres abonnés à partir de ce modèle.

NB : Dans cet exemple, nous partons du principe que le distributeur est déjà configuré. Dans tous les scripts, nous avons recours à des paramètres de template pour faciliter le remplacement de valeurs telles que le nom de la base publiée, etc.

Expert SQL Server - Réplication - Initialisation d'un abonné par sauvegarde/restauration - SQL Server  - param

1) Création d’une BDD à répliquer

En premier lieu, sur l’instance A, nous allons créer une BDD lambda avec une table contenant un jeu de données générées aléatoirement :

2) Activer la publication sur la base à publier

Activer la publication de la BDD créée précédemment, comme suit :

3) Créer une publication transactionnelle

Créer une réplication transactionnelle sur la BDD lambda, en spécifiant le nom de la publication.

4) Création de l’agent de capture de la publication

Création d’un agent de snapshot sur la publication créée à l’étape d’avant :

5) Ajout d’un article

Ajout d’un article dans la publication, en l’occurrence la table créée précédemment :

6) Création de la base de données, futur abonné

On se connecte sur l’instance qui hébergera une copie de la base de données publiée qui deviendra abonnée par la suite.

7) Création de l’abonné 1

Une fois la base de données secondaire créée, nous passons à la création de l’abonnement avec les options par défaut.

8) Initialisation de l’abonné 1

8) Vérification de la synchronisation de l’abonné 1

Juste pour la forme, on vérifie que la base abonnée a bien été synchronisée en comparant le nombre de lignes présente de chaque côté, respectivement sur la base de données publiée et la abse de données abonnée :

8) Arrêt de l’agent de lecture

On se connecte sur l’instance qui héberge la distribution et on stoppe purement et simplement l’agent de lecture, qui correspond à un  job dont le nom est récupéré dynamiquement.

9) Vérification de la synchronisation de l’abonné 1

A intervalle régulier, on vérifie que la liste des transactions en attente de réplication, ce qui correspond à la colonne Undelivcmdsindistdb. Il faut qu’elle soit à 0 pour tous les abonnés de la publication concernée (1 abonné par ligne). Dans l’exemple  suivant, il n’y a qu’un abonné mais dans l’absolu, il pourrait y en avoir plusieurs.

10) Sauvegarde de l’abonné 1

Il n’y a plus aucune transaction en attente de réplication, tout abonnés confondu s’il y en a plusieurs. Nous sauvegardons l’abonné pour la création et l’initialisation d’une autre base abonnée.

11) Restauration sur une future base abonné 2

Une fois la sauvegarde effectuée, nous procédons à la création/restauration d’une futur base de données abonnée, en spécifiant l’option KEEP_REPLICATION. Elle permet de conserver les objets tels que les PS liées à la réplication lors d’une restauration, typiquement :

  • sp_MSins_dboRandomData
  • sp_MSdel_dboRandomData
  • sp_MSupd_dboRandomData

12) Création de l’abonné 2

Une fois la base de données 3 restaurée, nous passons à la création de l’abonnement en spécifiant que nous ne souhaitons pas de synchronisation avec l’option @sync_type = ‘none’.

Les étapes 11 et 12 seront renouvellées autant de fois que d’abonnés supplémentaires à créer. Pour rappel, cela implique de suspendre la réplication pour la totalité des abonnés déjà présents. Si la réplication a été réactivée entre temps et qu’on souhaite ajouter d’autres abonnés par la suite, dans ce cas, il faudra repartir de l’étape 8 puis répéter les étapes 11 & 12 à hauteur du nombres d’abonnés à ajouter.

13) Injection de nouvelles données sur la base de données publiée

14) Démarrage de l’agent de lecture

On se connecte sur l’instance qui héberge la distribution et on démarre l’agent de lecture stoppé précédemment.

15) Vérification de la synchronisation des abonnés 1 & 2

A intervalle régulier, on vérifie que toutes les bases de données abonnées ont bien été synchronisées en comparant le nombre de lignes présentes de chaque côté :

Auteur

Expert SQL Server - Réplication - Initialisation d'un abonné par sauvegarde/restauration - SQL Server  - avatar_ninja_tete-150x150
Sarah Bessard
Experte SQL Server Prod/Etude avec un bonus sur la BI, les maîtres mots sont : performance, industrialisation, méthodologie & bonne humeur. Besoin d'une expertise SQL Server ? N'hésitez pas à me contacter.

Articles liés


Leave a comment

Your email address will not be published.

error: