Partager via

Comment la réplication de fusion détecte et résout les conflits

La réplication de fusion permet à plusieurs nœuds d’apporter des modifications de données autonomes, de sorte que des situations existent dans lesquelles une modification apportée à un nœud peut entrer en conflit avec une modification apportée aux mêmes données à un autre nœud. Dans d’autres cas, l’Agent de fusion rencontre une erreur telle qu’une violation de contrainte et ne peut pas propager une modification apportée à un nœud particulier vers un autre nœud. Cet article décrit les types de conflits, la façon dont les conflits sont détectés et résolus et les facteurs qui affectent la détection et la résolution.

Détecter et résoudre les conflits

L’Agent de fusion détecte les conflits à l’aide de la lineage colonne de la MSmerge_contents table système ; si le suivi au niveau des colonnes est activé pour un article, la COLV1 colonne est également utilisée. Ces colonnes contiennent des métadonnées sur le moment où une ligne ou une colonne est insérée ou mise à jour, et sur les nœuds d’une topologie de réplication de fusion qui ont apporté des modifications à la ligne ou à la colonne. Vous pouvez utiliser la procédure stockée système sp_showrowreplicainfo pour afficher ces métadonnées.

Lorsque l’Agent de fusion énumère les modifications à appliquer pendant la synchronisation, elle compare les métadonnées pour chaque ligne au niveau du serveur de publication et de l’abonné. L’Agent de fusion utilise ces métadonnées pour déterminer si une ligne ou une colonne a changé à plusieurs nœuds de la topologie, ce qui indique un conflit potentiel. Une fois qu’un conflit est détecté, l’Agent de fusion lance le programme de résolution de conflit spécifié pour l’article avec un conflit et utilise le programme de résolution pour déterminer le gagnant du conflit. La ligne gagnante est appliquée au serveur de publication et à l'Abonné tandis que les données de la ligne perdante sont consignées dans une table de conflits.

Les conflits sont résolus automatiquement et immédiatement par l’Agent de fusion, sauf si vous avez choisi la résolution interactive des conflits pour l’article. Pour plus d’informations, consultez Microsoft Replication Interactive Conflict Resolver. Si vous modifiez manuellement la ligne gagnante pour un conflit à l’aide de la visionneuse de conflits de réplication de fusion, l’Agent de fusion applique la version gagnante de la ligne au serveur perdant lors de la prochaine synchronisation.

Consigner les conflits résolus

Une fois que l’Agent de fusion a résolu le conflit en fonction de la logique du programme de résolution de conflit, il journalise les données de conflit en fonction du type de conflit :

  • Pour le conflit entre UPDATE et INSERT, il enregistre la version perdante de la ligne dans la table des conflits pour l’article, nommée selon le format conflict_<PublicationName>_<ArticleName>. Les informations générales sur les conflits, telles que le type de conflit, sont écrites dans la table MSmerge_conflicts_info.

  • En cas de conflits DELETE, il écrit la version perdante de la ligne dans la table MSmerge_conflicts_info. Lorsqu’une suppression perd contre une mise à jour, il n’y a plus de données pour la ligne perdante (car il s’agissait d’une suppression), donc rien n’est écrit dans conflict_<PublicationName>_<ArticleName>.

Les tables de conflit pour chaque article sont créées dans la base de données de publication, la base de données d’abonnement ou les deux (valeur par défaut), en fonction de la valeur spécifiée pour le @conflict_logging paramètre de sp_addmergepublication. Chaque table en conflit a la même structure que l’article sur lequel elle est basée, avec l’ajout de la colonne origin_datasource_id. L’Agent de fusion supprime les données de la table de conflit si elles sont antérieures à la durée de rétention des conflits pour la publication, qui est spécifiée à l’aide du paramètre @conflict_retention de sp_addmergepublication (la valeur par défaut est de 14 jours).

La réplication fournit le visualiseur de conflits de réplication et des procédures stockées (sp_helpmergearticleconflicts, sp_helpmergeconflictrows, et sp_helpmergedeleteconflictrows) pour afficher les données en conflit. Pour plus d’informations, consultez Résolution des conflits pour la réplication par fusion.

Facteurs qui affectent la résolution des conflits

Il existe deux facteurs qui affectent la façon dont l’Agent de fusion résout un conflit qu’il a détecté :

  • Type d’abonnement : client ou serveur (que l’abonnement soit un abonnement par extraction ou un abonnement Push n’affecte pas la résolution des conflits).

  • Type de suivi des conflits utilisé : niveau ligne, niveau colonne ou enregistrement logique.

Types d’abonnement

Lorsque vous créez un abonnement, en plus de spécifier s’il s’agit d’un abonnement push ou d’extraction, vous spécifiez s’il s’agit d’un abonnement client ou serveur ; une fois qu’un abonnement est créé, le type ne peut pas être modifié (dans les versions précédentes de SQL Server, les abonnements client et serveur ont été appelés respectivement des abonnements locaux et globaux).

Un abonnement avec une valeur de priorité affectée (de 0.00 à 99.99) est appelé abonnement au serveur ; un abonnement utilisant la valeur de priorité du serveur de publication est appelé abonnement client. En outre, les Abonnés disposant d’abonnements serveur peuvent republier des données sur d’autres Abonnés. Le tableau suivant récapitule les principales différences et utilisations de chaque type d’Abonné.

Type Valeur de priorité Utilisé
Serveur Affecté par l’utilisateur Lorsque vous souhaitez que différents Abonnés aient des priorités différentes.
Client 0,00, mais les modifications apportées aux données prennent la valeur de priorité de Publisher après la synchronisation Lorsque vous souhaitez que tous les Abonnés aient la même priorité et que le premier Abonné qui fusionne avec l'Éditeur remporte le conflit.

Si une ligne est modifiée dans un abonnement client, aucune priorité n’est affectée à la modification tant que l’abonnement n’est pas synchronisé. Pendant la synchronisation, les modifications apportées à l’Abonné reçoivent la priorité du serveur de publication et conservent cette priorité pour les synchronisations suivantes. Dans un sens, l'éditeur assume la propriété de la modification. Ce comportement permet au premier Abonné de se synchroniser avec le serveur de publication afin de gagner les conflits suivants avec d’autres Abonnés pour une ligne ou une colonne donnée.

Lorsque vous modifiez une ligne dans un abonnement serveur, la priorité de l’abonnement est stockée dans les métadonnées de la modification. Cette valeur de priorité accompagne la ligne modifiée lorsqu’elle fusionne avec les modifications apportées par d’autres abonnés. Cela garantit qu’une modification apportée par un abonnement de priorité supérieure ne perd pas à une modification ultérieure apportée par un abonnement avec une priorité inférieure.

Un abonnement ne peut pas avoir de valeur de priorité explicite supérieure à son Éditeur. Dans une topologie de réplication par fusion, Publisher de niveau supérieur a toujours une valeur de priorité explicite de 100,00. Tous les abonnements à cette publication doivent avoir une valeur de priorité inférieure à cette valeur. Dans une topologie de republication :

  • Si l’Abonné republie des données, l’abonnement doit être un abonnement serveur avec une valeur de priorité inférieure au serveur de publication au-dessus de l’Abonné.

  • Si l’abonné ne republie pas les données (car elles se trouvent au niveau feuille de l’arborescence de republication), l’abonnement doit être un abonnement client.

Pour plus d’informations sur les abonnements et les priorités du serveur, consultez Exemple de résolution des conflits de fusion en fonction du type d’abonnement et des priorités affectées.

Notification de conflit retardée

Une notification de conflit retardée peut se produire avec des abonnements serveur qui ont des priorités de conflit différentes. Considérez le scénario suivant, dans lequel les modifications non conflictuelles sont échangées entre le serveur de publication et un Abonné de priorité inférieure qui entraînent des modifications en conflit lorsqu’un Abonné à priorité supérieure se synchronise avec le serveur de publication :

  1. L'éditeur et un abonné à faible priorité, nommé LowPrioritySub, échangent des modifications sur plusieurs synchronisations sans conflit.

  2. Un abonné prioritaire, nommé HighPrioritySub, ne s’est pas synchronisé avec Publisher depuis un certain temps et a apporté des modifications aux mêmes lignes que celles modifiées par l’abonné LowPrioritySub.

  3. L’abonné HighPrioritySub se synchronise avec Publisher et remporte les conflits entre ses modifications et celles de l’abonné LowPrioritySub, car il a une priorité plus élevée que ce dernier. L'éditeur contient désormais les modifications apportées par l'abonné HighPrioritySub.

  4. L’abonné LowPrioritySub fusionne ensuite avec Publisher et télécharge un grand nombre de modifications en raison des conflits avec l’abonné HighPrioritySub.

Cette situation peut poser problème lorsque l’abonné ayant la priorité la plus faible a apporté des modifications aux mêmes lignes qui sont désormais perdantes dans le conflit. Cela peut entraîner une perte de toutes les modifications apportées par cet Abonné. Une solution potentielle à ce problème consiste à s’assurer que tous les Abonnés ont la même priorité, sauf si la logique métier dicte autrement.

Niveau de suivi

Si une modification de données est considérée comme un conflit dépend du type de suivi des conflits que vous définissez pour un article : niveau ligne, niveau colonne ou niveau enregistrement logique. Pour plus d’informations sur le suivi logique au niveau des enregistrements, consultez Conflit de réplication avancée - Résolution dans l’enregistrement logique.

Lorsque des conflits sont reconnus au niveau de la ligne, les modifications apportées aux lignes correspondantes sont jugées en conflit, que les modifications soient apportées à la même colonne ou non. Par exemple, supposons qu’une modification soit apportée à la colonne d’adresse d’une ligne Publisher, et qu’une deuxième modification est apportée à la colonne numéro de téléphone de la ligne Abonné correspondante (dans la même table). Avec le suivi au niveau des lignes, un conflit est détecté lorsque des modifications sont apportées à la même ligne. Avec le suivi au niveau des colonnes, aucun conflit n’est détecté, car les modifications ont été apportées à différentes colonnes dans la même ligne.

Pour le suivi au niveau des lignes et des colonnes, la résolution du conflit est la même : toute la ligne de données est remplacée par les données du gagnant du conflit (pour le suivi au niveau de l’enregistrement logique, la résolution dépend de la propriété logical_record_level_conflict_resolutionde l’article).

La sémantique de l’application détermine généralement l’option de suivi à utiliser. Par exemple, si vous mettez à jour les données client qui sont généralement entrées en même temps, telles qu’une adresse et un numéro de téléphone, le suivi au niveau des lignes doit être choisi. Si le suivi au niveau des colonnes a été choisi dans cette situation, les modifications apportées à l’adresse du client dans un emplacement et le numéro de téléphone du client dans un autre emplacement ne seraient pas détectées comme un conflit : les données seraient fusionnées lors de la synchronisation et l’erreur serait manquée. Dans d’autres situations, la mise à jour de colonnes individuelles à partir de différents sites peut être le choix le plus logique. Par exemple, deux sites peuvent avoir accès à différents types d’informations statistiques sur un client, comme le niveau de revenu et le montant total des achats de cartes de crédit. La sélection du suivi au niveau des colonnes garantit que les deux sites peuvent entrer les données statistiques pour différentes colonnes sans générer de conflits inutiles.

Remarque

Si votre application ne nécessite pas de suivi au niveau des colonnes, il est recommandé d’utiliser le suivi au niveau des lignes (valeur par défaut), car elle entraîne généralement de meilleures performances de synchronisation. Si le suivi des lignes est utilisé, la table de base peut inclure un maximum de 1 024 colonnes, mais les colonnes doivent être filtrées à partir de l’article afin qu’un maximum de 246 colonnes soit publié. Si le suivi de colonnes est utilisé, la table de base peut inclure 246 colonnes au maximum.

Types de conflits

Bien que la plupart des conflits soient liés aux mises à jour (une mise à jour à un nœud est en conflit avec une mise à jour ou une suppression sur un autre nœud), il existe d’autres types de conflits. Chaque type de conflit abordé dans cette section peut se produire pendant la phase de chargement ou la phase de téléchargement du traitement de fusion. Le traitement du chargement est le premier rapprochement des modifications effectuées au cours d’une session de fusion particulière. Il s’agit de la phase pendant laquelle l’agent de fusion réplique les modifications de l’abonné vers Publisher. Les conflits détectés pendant ce traitement sont appelés conflits de chargement. Le traitement du téléchargement implique le déplacement des modifications du serveur de publication vers l’Abonné et se produit après le traitement du chargement. Les conflits pendant cette phase de traitement sont appelés conflits de téléchargement.

Pour plus d’informations sur les types de conflits, consultez MSmerge_conflicts_info, en particulier les colonnes conflict_type et reason_code.

Conflits de mises à jour simultanées

L’Agent de fusion détecte les conflits de mise à jour lorsqu’une mise à jour vers une ligne (ou une colonne ou un enregistrement logique) à un nœud est en conflit avec une autre mise à jour vers la même ligne sur un autre nœud. Dans ce cas, le comportement du programme de résolution par défaut consiste à envoyer la version gagnante de la ligne au nœud perdant et journaliser la version de ligne perdante dans la table de conflit d’articles.

Conflits de mise à jour-suppression

L'Agent de fusion détecte les conflits mise à jour-suppression lorsqu'une mise à jour des données sur un nœud entre en conflit avec une suppression sur un autre nœud. Dans ce cas, l’Agent de fusion met à jour une ligne ; Toutefois, lorsque l’Agent de fusion recherche cette ligne à la destination, elle ne peut pas trouver la ligne car elle a été supprimée. Si le gagnant est le nœud qui a mis à jour la ligne, la suppression au niveau du nœud perdant est ignorée et l’Agent de fusion envoie la ligne nouvellement mise à jour au perdant du conflit. L’Agent de fusion enregistre des informations sur la version perdante de la ligne dans la table MSmerge_conflicts_info.

Conflits dus à une modification échouée

L’Agent de fusion déclenche ces conflits lorsqu’il ne peut pas appliquer de modification particulière. Cela se produit généralement en raison d’une différence dans les définitions de contrainte entre le distributeur et l’abonné, et l’utilisation de la propriété NOT FOR REPLICATION (NFR) sur la contrainte. Voici quelques exemples :

  • Un conflit de clé étrangère au niveau de l’abonné, qui peut se produire lorsque la contrainte côté abonné n’est pas marquée comme NFR.

  • Différences entre les contraintes de Publisher et celles des abonnés, et les contraintes ne sont pas marquées comme NFR.

  • Indisponibilité d’objets dépendants chez l’abonné. Par exemple, si vous publiez une vue, mais pas la table sur laquelle cette vue dépend, une erreur se produit si vous essayez d’insérer via cette vue au niveau de l’abonné.

  • Joindre une logique de filtrage pour une publication qui ne correspond pas aux contraintes de clé primaire et de clé étrangère. Les conflits peuvent se produire lorsque le moteur relationnel SQL Server tente d’honorer une contrainte, mais que l’Agent de fusion respecte la définition de filtre de jointure entre les articles. L’Agent de fusion ne peut pas appliquer la modification au niveau du nœud de destination en raison des contraintes au niveau de la table, ce qui entraîne un conflit.

  • Les conflits à cause de violations d'index unique, de contraintes d'unicité ou de violation de clé primaire peuvent se produire si des colonnes d'identité sont définies pour l'article et que la gestion automatisée des identités n'est pas utilisée. Il peut s’agir d’un problème si deux Abonnés utilisaient la même valeur d’identité pour une ligne nouvellement insérée. Pour plus d’informations sur la gestion des plages d’identité, consultez Répliquer les colonnes d’identité.

  • Conflits en raison d’une logique de déclenchement empêchant l’Agent de fusion d’insérer une ligne dans la table de destination. Considérons un déclencheur de mise à jour défini au niveau de l’abonné ; le déclencheur n’est pas marqué comme NFR et comprend un ROLLBACK dans sa logique. En cas d’échec, le déclencheur émet un ROLLBACK de la transaction, ce qui entraîne la détection d’un conflit de modification échoué par l’agent de fusion.

Contenu connexe

  • Last updated on