Ce petit billet offre un aperçu du fonctionnement de la réplication de fusion, également appelée « Merge replication ». Pour une présentation générale de la réplication, vous pouvez aller ici.
Présentation rapide de la réplication de fusion et rappel des scénarii d’utilisation
La réplication de fusion (ou merge) est usuellement appropriée dans les cas suivants :
- Plusieurs abonnés (bases de données liées à une base de données SQL Server locale) peuvent mettre à jour les mêmes données à différents moments et propager ces modifications à l’éditeur et à d’autres abonnés.
- Des abonnés doivent recevoir des données, apporter des modifications en étant offline et synchroniser ultérieurement ces modifications avec l’éditeur et d’autres abonnés partageant la même session de réplication.
- Chaque abonné requiert une partition de données différentes (dans le cas d’un load balancing, par exemple).
- Il y a un risque potentiel de conflits de mises-à-jour ou alors, qu’on doit avoir la possibilité de les détecter et de les résoudre de manière proactive par fusion des opérations de mises-à-jour.
- La réplication nécessite le résultat des modifications des données au lieu de devoir accéder aux états intermédiaires des données répliquées. Par exemple, si une ligne change un certain nombre de fois sur un abonné avant qu’il se synchronise avec l’éditeur, la ligne ne change qu’une seule fois sur le serveur de publication pour refléter le résultat final des modifications (c’est-à-dire prise en compte du dernier changement).
Comment SQL Server gère la réplication de fusion ?
| Pour mieux comprendre comment le Snapshot Agent travaille exactement, allez ici. |
SQL Server traite via un ensemble de mécanismes appelés SQL Server Replication Agents la réplication de fusion.
Dans le cas de la réplication de fusion, la phase de snapshot fonctionne différemment par rapport à la réplication transactionnelle (et de snapshot). En effet, le Log Reader Agent n’existe pas, ce qui signifie donc qu’aucun marqueur n’est utilisé. De plus, lors du lancement du Snapshot Agent pour la réplication de fusion, aucun verrou n’est posé sur l’ensemble de la base de données.
Le schéma ci-après résume le fonctionnement d’une réplication de fusion :
Dans ce type de réplication, le Merge Agent joue le rôle du Log Reader Agent (vérification transactionnelle) et de Distributor
Agent (application des changements détectés dans la base de distribution, puis propagation vers les abonnés), ce qui signifie qu’il s’occupe à synchroniser tout changement entre l’éditeur et ses abonnés. Les flèches rouges indiquent les accès en écriture tandis que les flèches vertes représentent les accès en lecture. On notera que le Merge Agent est placé soit sur le même serveur que le distributeur, soit sur le même serveur que l’abonné, selon le mode de récupération choisi. En effet, en mode push le Merge Agent est placé sur le distributeur tandis qu’en mode pull, il est placé sur l’abonné.
En l’absence de Log Reader Agent, le monitoring et l’enregistrement des changements des articles à publier est assuré par des triggers (déclencheurs) et des tables qui sont ajoutés au sein de la base de données de publication (éditeur). Et dans la mesure où des données peuvent également être propagées des abonnés vers l’éditeur, les mêmes triggers et tables sont également ajoutés au sein de chaque base de données abonnée.
La convention de nommage des tables créées par SQL Server est la suivante : MSmerge_XXX_HHH, où HHH est un long caractère hexadécimal qui correspond à l’identificateur interne de l’article concerné, et où XXX est l’un des caractères suivants :
- « ins » pour le trigger d’insertion.
- « upd » pour le trigger de mise-à-jour.
- « del » pour le trigger de suppression.
Ces 3 triggers sont responsables de l’enregistrement toute modification effectuée au sein d’un article de la base de données de publication (ou de souscription selon le contexte). Et outre ces triggers, il existe d’autres triggers responsables des changements de schémas d’articles publiés (dont la nomenclature est assez explicite quant à leur rôle) : MSmerge_tr_alterschemaonly, MSmerge_tr_altertable, MSmerge_tr_altertrigger et MSmerge_tr_alterview. Leurs informations récupérées sont également stockées dans les tables systèmes préfixées d’un MSMerge_.
Par la suite, toutes les informations enregistrées au sein des tables systèmes par les triggers sont récupérées par le Merge Agent. Par défaut, SQL Server crée autant de Merge Agents que d’abonné (que ce soit en mode push ou en mode pull), et la règle de nommage est la suivante :
- Si le mode push est choisi : sur l’instance de l’éditeur, <Editeur>-<Base de publication>-<Publication>-<Abonné>-<Numéro>.
- Si le mode pull est choisi : sur l’instance de chaque abonné, <Editeur>-<Base de publication>-<Publication>-<Abonné>-<Base de souscription>-<Numéro>.
Dans les deux cas, <Numéro> est un petit chiffre utilisé par SQL Server pour éviter tout conflit de nommage, <Abonné> est le nom de l’abonné configuré et <Publication>, le nom de l’éditeur configuré. Quant à <Editeur>, il représente, ici, le serveur au sein duquel se trouve la base de publication.
Résolution des conflits
Par ailleurs, les abonnés pouvant modifier des articles répliqués, puis soumettre leurs modifications vers l’éditeur (via le Merge Agent), des conflits de mises-à-jour peuvent intervenir, d’autant plus qu’un abonné peut également être l’éditeur d’un autre abonné. La résolution des conflits par le Merge Agent se fait via principalement 2 types d’approche (au choix):
-
Approche par défaut (default resolver): un niveau de priorité (de 0 à 100) est attribué à chaque « nœud » de la topologie de la réplication (éditeur et abonnés). L’éditeur est celui qui possède toujours le plus haut niveau de priorité (100). Lorsque 2 nœuds sont en conflit, le Merge Agent choisi d’appliquer les modifications sur le nœud ayant le niveau de priorité le plus élevé des deux.
Pour mieux comprendre le principe, prenons en exemple le schéma suivant :
Le nœud A est le premier éditeur (avec un niveau de priorité égal à 100), et les nœuds C, D, E sont des abonnées de type « serveur » avec respectivement un niveau de priorité 50, 75 et 25. C, en outre, est l’éditeur d’un autre abonné : le nœud G, de priorité 80. B est un client, sachant que dans le cas d’un client le niveau de priorité correspond au moment de sa synchronisation avec son éditeur.
Au vu de la topologie de réplication de fusion de notre schéma, on peut noter que plusieurs étapes de synchronisation sont nécessaires afin de propager tout changement vers tout nœud. Admettons qu’un changement ait eu lieu au sein du nœud G, afin de propager un tel changement, une synchronisation doit d’abord avoir lieu entre G et C, puis C avec A, puis A avec B, D et E.
Si un conflit de changements est détecté entre un changement au sein de D et le changement original à propager, le changement de D échouera dans la mesure où G a le niveau de priorité le plus élevé (dans le cas échéant, G échouerait, et A aurait à se resynchroniser avec B, C et E pour propager les changements de D, puis C avec son abonné G pour en faire de même).
Le tableau ci-dessous résume le résultat de la résolution de conflits potentiels au sein de notre topologie par SQL Server (via le Merge Agent) :
| Nœud en conflit avec… | … un nœud correspondant à | Résultat de la résolution |
| A | N’importe quel autre nœud | A gagne. |
| B | C | Le premier nœud qui se synchronise avec A gagne. |
| B | D | Le premier nœud qui se synchronise avec A gagne. |
| B | E | Le premier nœud qui se synchronise avec A gagne. |
| C | D | D gagne. |
| C | E | C gagne. |
| D | E | D gagne. |
| D | G | G gagne. |
| E | G | G gagne. |
- Approche personnalisée (custom resolver): l’utilisateur peut définir des règles de gestion de conflits. Plus d’informations ici : http://msdn.microsoft.com/en-us/library/ms151257.aspx.
Pour aller plus loin…
Dans un prochain billet, nous traiterons de la mise-en-place de la réplication transactionnelle.
Mohamed A. Cherif - DBMS, BI, Big Data... 