Présentation de la réplication de fusion
La réplication de fusion, comme la réplication transactionnelle, démarre généralement avec un instantané des objets et des données de la base de données de publication. Les modifications de données et de schéma ultérieures qui sont effectuées sur le serveur de publication et sur les Abonnés sont suivies avec des déclencheurs. L'abonné est synchronisé avec l'éditeur lorsqu'il est connecté au réseau et il échange toutes les lignes qui ont changé entre l'éditeur et l'abonné depuis la dernière synchronisation.
La réplication de fusion est généralement utilisée dans des environnements de serveur à client. La réplication de fusion est appropriée dans les 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.
des abonnés doivent recevoir des données, apporter des modifications hors connexion et synchroniser ultérieurement ces modifications avec l'éditeur et d'autres abonnés ;
Chaque Abonné requiert une partition de données différente.
Des conflits peuvent se produire et, le cas échéant, vous devez pouvoir les détecter et les résoudre.
L'application requiert le résultat des modifications des données au lieu de devoir accéder aux états intermédiaires des données. Par exemple, si une ligne change cinq fois sur un Abonné avant qu'il se synchronise avec un serveur de publication, 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 la cinquième valeur).
La réplication de fusion permet à plusieurs sites de fonctionner de manière autonome, pour fusionner ensuite leurs mises à jour en un résultat unique et uniforme. Étant donné que les mises à jour sont effectuées sur plusieurs nœuds, les mêmes données ont pu être mises à jour par le serveur de publication et par plusieurs Abonnés. Par conséquent, des conflits peuvent se produire quand des mises à jour sont fusionnées ; la réplication de fusion fournit plusieurs moyens de gérer ces conflits.
Afin d'assurer le suivi des modifications, la réplication de fusion (et la réplication transactionnelle avec mise à jour d'abonnements en attente) doivent pouvoir identifier de manière unique chaque ligne dans chaque table publiée. Pour ce faire, la réplication de fusion ajoute la colonne rowguid à chaque table, à moins que la table ne dispose déjà d'une colonne de type de données uniqueidentifier avec la propriété ROWGUIDCOL définie (auquel cas cette colonne est utilisée). Si la table est supprimée de la publication, la colonne rowguid est supprimée, si une colonne existante était utilisée pour le suivi, la colonne n'est pas supprimée. Un filtre ne doit pas inclure la colonne rowguidcol utilisée par la réplication pour identifier les lignes. La fonction newid() est fournie comme valeur par défaut pour la colonne rowguid ; toutefois, les clients peuvent fournir un GUID pour chaque ligne en cas de besoin. Cependant, ne spécifiez pas la valeur 00000000-0000-0000-0000-000000000000.
Pour des informations sur la mise en œuvre de la réplication de fusion, consultez Conception et implémentation (réplication).
Pour des informations sur les scénarios courants qui impliquent la réplication de fusion, consultez Réplication de données entre un serveur et des clients.
Voir aussi