Réplication – Initialisation d’un abonné par sauvegarde avec édition de la réplication

---

Dans cet article, nous allons créer une publication transactionnelle, initialiser un abonné à partir d’une sauvegarde et enfin permettre l’édition de la réplication. Nativement, il n’est pas possible de modifier en totalité une publication avec l’initialisation d’un abonné par sauvegarde Cette méthode est appropriée dans les cas suivants :

• Structure identique sur les bases publiée et abonnées
• Volumétrie à répliquer importante

Pour finir, nous verrons comment rendre cette réplication éditable car la prise en compte de nouveaux articles, entre autres, n’est pas native sur l’abonné lorsqu’il a été initialisé par sauvegarde..

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.

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

En premier lieu, sur l’instance A, nous allons créer une BDD lambda avec une deux tables contenant chacune 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.

Notez que l’option @allow_initialize_from_backup est à true.

NB : Pour une publication déjà existante, on pourra modifier la publication comme suit après coup :

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 :

6) Désactiver la purge des transactions sur le distributeur

Sur l’instance de distribution, désactiver le job de purge des transactions de la réplication. Le nom du job varie suivant le nom de la base de distribution utilisée par la publication.

7) Sauvegarde de la BDD publiée

Une fois la réplication configurée, lancer une sauvegarde de la base publiée :

8) Restauration sur l’abonné

Sur l’instance B, celle qui héberge la futur base abonnée, lancer une restauration à partir de la sauvegarde créée précédemment :

9) Création de l’abonné

Lors de la création de l’abonné, il y a deux paramètres à retenir dans la création de l’abonné :

• @sync_type = initialize with backup
• @backupdevicename = chemin de la sauvegarde utilisée précédemment

NB : On peut très bien s’appuyer sur un plan de sauvegarde existant incluant les logs pour l’initialisation de l’abonné (by-pass de l’étape de sauvegarde complète) mais la dernière sauvegarde de logs à restaurer sur l’abonné doit être la plus récente possible. Le cas échéant, au moment de l’initialisation de l’abonné, on obtiendra le message d’erreur suivant :

Retry the operation again with a more up-to-date log, differential, or full database backup

10) Réactiver la purge des transactions sur le distributeur

Sur l’instance de distribution, réactiver le job de purge des transactions de la réplication. Comme indiqué précédemment, le nom du job varie suivant le nom de la base de distribution utilisée par la publication.

11) Vérification de la réplication

Sur la base publiée, on relève le nombre de lignes sur l’article répliqué :

Qu’on compare avec la base abonnée :

!!! FIN !!! Enfin presque…

Mais qu’en est-il lorsqu’on ajoute un article dans la publication par la suite, après une initialisation par sauvegarde ? RIEN, Il ne se passe rien, aucune données ne remonte sur l’abonné. Il va falloir modifier quelques paramètres pour rendre la synchronisation de l’abonné fonctionnelle.

12) Propriétés de la publication

Nous allons donc modifier 3 propriétés sur la publication :

• allow_anonymous = false, cette option est indissociable de celle qui nous intéresse, voir ci-dessous
• immediate_sync = false, cette option permet de passer en mode asynchrone pour générer un snapshot différentiel  (remontée de l’article ajouté sur l’abonné)
• allow_initialize_from_backup = false, cette option permet de revenir à une initialisation par snapshot de l’abonné

13) Synchronisation automatique de l’abonné

La petite touche “Brico Dépôt” : la synchronisation de l’abonné devra être modifiée en réalisant un UPDATE dans une table système liée à la réplication. Cette mise à jour consiste à rendre la synchronisation de l’abonné automatique, comme suit :

La publication et l’abonné sont désormais prêt à recevoir de nouveaux articles !

14) Ajout d’un article

L’ajout d’article ne diffère en rien (table RandomData2), on procède comme à l’accoutumée avec un refresh de l’abonné et la génération d’un snapshot différentiel en prime :

15) Vérification de la réplication

Sur la base publiée, on relève le nombre de lignes sur l’article répliqué en seconde noce :

Qu’on compare avec la base abonnée :