Réplication de fusion

Comme la réplication transactionnelle, la réplication de fusion commence généralement par un instantané des objets de la base de données et des données de publication. Les modifications de données et les modifications de schéma apportées chez le Publieur et aux abonnés sont suivies par des déclencheurs. L’Abonné se synchronise avec le serveur de publication lorsqu’il est connecté au réseau et échange toutes les lignes qui ont changé entre le serveur de publication et l’Abonné depuis la dernière synchronisation.

La réplication de fusion est généralement utilisée dans les environnements serveur à client. La réplication de fusion est appropriée dans l’une des situations suivantes :

• Plusieurs Abonnés peuvent mettre à jour les mêmes données à différents moments et propager ces modifications au serveur de publication et à d’autres abonnés.

• Les abonnés doivent recevoir des données, apporter des modifications hors connexion et synchroniser ultérieurement les modifications avec le serveur de publication et d’autres abonnés.

• Chaque Abonné nécessite une partition différente de données.

• Les conflits peuvent se produire et, quand ils le font, vous avez besoin de la possibilité de les détecter et de les résoudre.

• L’application nécessite une modification nette des données plutôt que l’accès aux états de données intermédiaires. Par exemple, si une ligne change cinq fois sur un Abonné avant de se synchroniser avec un serveur de publication, la ligne ne change qu’une seule fois sur le serveur de publication pour refléter la modification des données nettes (autrement dit, la cinquième valeur).

La réplication de fusion permet à différents sites de fonctionner de manière autonome et de fusionner ultérieurement les mises à jour en un résultat unique et uniforme. Étant donné que les mises à jour sont effectuées à plusieurs nœuds, les mêmes données peuvent avoir été mises à jour par le serveur de publication et par plusieurs abonnés. Par conséquent, les conflits peuvent se produire lorsque les mises à jour sont fusionnées et que la réplication de fusion offre plusieurs moyens de gérer les conflits.

La réplication de fusion est implémentée par l’Agent d’instantané SQL Server et l’Agent de fusion. Si la publication n’est pas filtrée ou utilise des filtres statiques, l’Agent d’instantané crée un instantané unique. Si la publication utilise des filtres paramétrables, l’Agent d’instantané crée un instantané pour chaque partition de données. L’Agent de fusion applique les instantanés initiaux aux Abonnés. Il fusionne également les modifications incrémentielles des données qui se sont produites sur le serveur de publication ou les Abonnés après la création de l’instantané initial, et détecte et résout les conflits en fonction des règles que vous configurez.

Pour permettre le suivi des modifications, la réplication de fusion (ainsi que la réplication transactionnelle avec mise à jour d'abonnements en attente) doit pouvoir identifier de manière unique chaque ligne dans chaque table publiée. Pour effectuer cette réplication de fusion, ajoute la colonne rowguid à chaque table, sauf si la table a déjà une colonne de type uniqueidentifier de données avec le ROWGUIDCOL jeu de propriétés (auquel cas cette colonne est utilisée). Si la table est supprimée de la composition, la rowguid colonne est supprimée ; si une colonne existante a été utilisée pour le suivi, la colonne n’est pas supprimée. Aucun filtre ne doit inclure le rowguidcol utilisé par la réplication pour identifier les lignes. La newid() fonction est fournie comme valeur par défaut pour la rowguid colonne, mais les clients peuvent fournir un guid pour chaque ligne si nécessaire. Toutefois, ne fournissez pas de valeur 00000000-0000-0000-0000-00000000000000000000.

Le diagramme suivant montre les composants utilisés dans la réplication de fusion.

de