Égal à égal - Détection de conflit dans la réplication d’égal à égal
S'applique à : 
SQL Server
La réplication transactionnelle d'égal à égal vous permet d'insérer, de mettre à jour et de supprimer des données sur un nœud quelconque dans une topologie, puis de propager les modifications aux autres nœuds. Comme vous pouvez modifier des données sur un nœud quelconque, les modifications de données sur des nœuds différents peuvent être en conflit les unes avec les autres. Si une ligne est modifiée au niveau de plusieurs nœuds, elle peut provoquer un conflit, voire la perte de la mise à jour, lorsque la ligne est propagée à d'autres nœuds.
La réplication d’égal à égal comprend une option permettant d’activer la détection des conflits dans une topologie d’égal à égal. Cette option permet d’éviter les problèmes issus de conflits non détectés, notamment le comportement incohérent des applications et les mises à jour perdues. Lorsque cette option est activée, par défaut, une modification en conflit est traitée comme une erreur critique qui provoque l'échec de l'Agent de distribution. En cas de conflit, la topologie reste dans un état incohérent jusqu'à la résolution du conflit et jusqu'au rétablissement de la cohérence des données dans la topologie.
Remarque
Pour éviter l'incohérence potentielle des données, faites-en sorte d'éviter les conflits dans une topologie d'égal à égal, même si la détection des conflits est activée. Afin de garantir que les opérations d'écriture pour une ligne particulière soient réalisées au niveau d'un seul nœud, les applications qui accèdent aux données et les modifient doivent partitionner les opérations d'insertion, de mise à jour et de suppression. Ce partitionnement garantit que les modifications apportées à une ligne donnée provenant d'un nœud sont synchronisées sur tous les autres nœuds de la topologie avant que cette ligne soit modifiée par un autre nœud. Si une application requiert des fonctionnalités avancées de détection et de résolution des conflits, utilisez la réplication de fusion. Pour plus d’informations, consultez Réplication de fusion et Détecter et résoudre des conflits de réplication de fusion.
Description des conflits et de la détection de conflit
Dans une base de données unique, les modifications apportées à une même ligne par des applications différentes ne provoquent pas de conflit. Cela est dû au fait que les transactions sont sérialisées et que des verrous traitent des modifications simultanées. Dans un système distribué asynchrone, tel que la réplication d'égal à égal, les transactions agissent indépendamment sur chaque nœud et aucun mécanisme ne sérialise les transactions sur plusieurs nœuds. Il est possible d'utiliser un protocole semblable à une validation en deux phases, mais cela affecte considérablement les performances.
Dans les systèmes tels que la réplication d'égal à égal, les conflits ne sont pas détectés lorsque les modifications sont validées au niveau d'homologues individuels. À la place, ils sont détectés lorsque ces modifications sont répliquées et appliquées à d'autres homologues. Dans la réplication d’égal à égal, les conflits sont détectés par les procédures stockées qui appliquent des modifications à chaque nœud en fonction une ou plusieurs colonnes masquées dans chaque table publiée.
Avant SQL Server 2019 (15.x) CU 13, SQL Server ajoutait une colonne masquée à chaque table publiée : $sys_p2p_cd_id. Cette colonne masquée stocke un ID qui associe un ID d'appelant que vous spécifiez pour chaque nœud et la version de la ligne.
À partir de SQL Server 2019 (15.x) CU 13 et versions ultérieures, si vous créez la publication d’égal à égal avec @p2p_conflictdetection_policy = 'lastwriter', SQL Server ajoute une colonne masquée supplémentaire à chaque table publiée : $sys_md_cd_id. Cette colonne masquée stocke la valeur DateTime en tant que type de données datetime2.
Pendant la synchronisation, l'Agent de distribution exécute des procédures pour chaque table. Ces procédures appliquent des opérations d'insertion, de mise à jour et de suppression provenant d'autres homologues. Si l’une de ces procédures détecte un conflit lorsqu’elle lit la ou les valeurs de la colonne masquée, elle déclenche l’erreur 22815 de niveau de gravité 16 :
A conflict of type '%s' was detected at peer %d between peer %d (incoming), transaction id %s and peer %d (on disk), transaction id %s
Par défaut, suite à cette erreur, l'Agent de distribution cesse d'appliquer des modifications à ce nœud. Pour plus d’informations sur la façon de traiter les conflits détectés, consultez Gestion des conflits.
Remarque
Seul un utilisateur qui se connecte par le biais de la connexion administrateur dédiée peut accéder à la colonne masquée. Pour obtenir des informations sur la connexion administrateur dédiée, consultez Connexion de diagnostic pour les administrateurs de base de données.
La réplication d'égal à égal détecte les types de conflits suivants :
Conflit d'insertions
Toutes les lignes de chaque table qui participe à la réplication d'égal à égal sont identifiées de façon unique à l'aide de valeurs de clés primaires. Un conflit d'insertions se produit lorsqu'une ligne avec la même valeur de clé a été insérée sur plusieurs nœuds.
Conflit de mises à jour
Se produit lorsque la même ligne a été mise à jour sur plusieurs nœuds.
Conflit d'insertion/mise à jour
Se produit si une ligne a été mise à jour sur un nœud et que la même ligne a été supprimée puis réinsérée sur un autre nœud.
Conflit d'insertion/suppression
Se produit si une ligne a été supprimée sur un nœud et que la même ligne a été supprimée puis réinsérée sur un autre nœud.
Conflit de mise à jour/suppression
Se produit si une ligne a été mise à jour sur un nœud et que la même ligne a été supprimée sur un autre nœud.
Conflit de suppressions
Se produit lorsqu'une ligne a été supprimée sur plusieurs nœuds.
Activation de la détection de conflit
Pour utiliser la détection de conflit, activez la détection pour tous les nœuds. Par défaut, la détection de conflit est activée lorsque vous configurez la réplication d’égal à égal dans SQL Server Management Studio. Nous vous recommandons d'activer la détection, même dans les scénarios où vous ne prévoyez pas de conflits. La détection de conflit peut être activée et désactivée en utilisant Management Studio ou les procédures stockées Transact-SQL :
Vous pouvez activer et désactiver la détection dans Management Studio en utilisant la page Options d’abonnement de la boîte de dialogue Propriétés de la publication ou la page Configurer la topologie de l’Assistant Configurer la topologie d’égal à égal.
Si vous configurez la détection de conflit à l’aide de Management Studio, l’agent de distribution est configuré pour cesser d’appliquer les modifications lorsqu’un conflit est détecté.
Vous pouvez également activer et désactiver la détection en utilisant les procédures stockées suivantes :
sp_configure_peerconflictdetection.
Si vous configurez la détection de conflit à l'aide de procédures stockées, vous pouvez spécifier si l'Agent de distribution doit cesser d'appliquer les modifications lorsqu'un conflit est détecté. Par défaut, l'agent doit cesser d'appliquer les modifications. Nous vous recommandons d'utiliser le paramètre par défaut.
Gestion des conflits
Lorsqu’un conflit se produit dans la réplication d’égal à égal, l’alerte de détection de conflit d’égal à égal est déclenchée. Configurez cette alerte pour être notifié en cas de conflit. Pour plus d’informations sur les alertes, consultez Utiliser les alertes pour les événements des agents de réplication.
Une fois que l'Agent de distribution s'est arrêté et que l'alerte a été déclenchée, utilisez l'une des approches suivantes pour gérer les conflits qui se sont produits :
Réinitialisez le nœud sur lequel le conflit a été détecté à partir de la sauvegarde d'un nœud qui contient les données requises (approche recommandée). Cette méthode garantit la cohérence des données.
Essayez de synchroniser de nouveau le nœud en permettant à l'Agent de distribution de continuer à appliquer les modifications :
Exécutez sp_changepublication : spécifiez 'p2p_continue_onconflict' pour le paramètre @property et true pour le paramètre @value.
Redémarrez l'Agent de distribution.
Vérifiez les conflits détectés en utilisant l'outil de résolution des conflits et déterminez les lignes qui étaient impliquées, le type de conflit et le vainqueur. Le conflit est résolu en fonction de la valeur de l'ID d'appelant que vous avez spécifiée pendant la configuration : la ligne provenant du nœud avec l'ID le plus élevé remporte le conflit. Pour plus d’informations, consultez Afficher les conflits de données pour les publications transactionnelles (SQL Server Management Studio).
Exécutez une validation pour garantir que les lignes en conflit ont convergé correctement. Pour plus d’informations, consultez Valider des données répliquées.
Remarque
Si les données ne sont pas cohérentes après cette étape, vous devez mettre à jour manuellement les lignes sur le nœud qui a la priorité la plus élevée, puis propager les modifications à partir de ce nœud. S'il n'y a plus de modifications en conflit dans la topologie, tous les nœuds bénéficieront d'un état cohérent.
Exécutez sp_changepublication : spécifiez 'p2p_continue_onconflict' pour le paramètre @property et false pour le paramètre @value.
Gérer automatiquement les conflits en donnant la priorité à la dernière écriture
À partir de SQL Server 2019 (15.x) CU 13, vous pouvez configurer la réplication d’égal à égal pour résoudre automatiquement les conflits en autorisant l’insertion ou la mise à jour la plus récente à remporter le conflit. Si l’une des deux écritures supprime la ligne, SQL Server donne la priorité à la suppression. Cette méthode est connue comme la « priorité à la dernière écriture ».
Utilisez des procédures stockées pour configurer la priorité à la dernière écriture. Consultez Configurer la détection et la résolution des conflits de dernière écriture. Vous ne pouvez pas configurer la priorité à la dernière écriture avec SQL Server Management Studio.
Remarque
La réplication d’égal à égal avec priorité à la dernière écriture dépend de la synchronisation des horloges des nœuds participants pour des résultats fiables. Si les horloges des serveurs participants deviennent trop éloignées, le résultat d’une résolution de conflit peut être inattendu et/ou indésirable. Par exemple, si le serveur A a une horloge précise, mais que le serveur B est une semaine à la traîne, le serveur A est choisi pour remporter chaque conflit, même s’il n’a pas été le dernier à mettre à jour la ligne de manière objective. S’il n’est pas possible de conserver les horloges dans le niveau de tolérance dont vous avez besoin pour la résolution des résultats, vous souhaiterez peut-être choisir une autre stratégie de résolution des conflits.