Détection des conflits dans la réplication d’égal à égal

La réplication transactionnelle d’égal à égal vous permet d’insérer, de mettre à jour ou de supprimer des données sur n’importe quel nœud d’une topologie et de propager les modifications de données aux autres nœuds. Étant donné que vous pouvez modifier des données sur n’importe quel nœud, les modifications de données sur différents nœuds peuvent entrer en conflit entre elles. Si une ligne est modifiée à plusieurs nœuds, elle peut provoquer un conflit ou même une mise à jour perdue lorsque la ligne est propagée à d’autres nœuds.

La réplication d’égal à égal dans SQL Server 2008 et versions ultérieures offre la possibilité d’activer la détection des conflits dans une topologie d’égal à égal. Cette option permet d’éviter les problèmes provoqués par des conflits non détectés, notamment le comportement incohérent de l’application et les mises à jour perdues. Avec cette option 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’à ce que le conflit soit résolu et que les données soient cohérentes dans la topologie.

Présentation des conflits et de la détection des conflits

Dans une base de données unique, les modifications apportées à la même ligne par différentes applications ne provoquent pas de conflit. Cela est dû au fait que les transactions sont sérialisées et que les verrous sont utilisés pour gérer les 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 il n’existe aucun mécanisme pour sérialiser les transactions entre plusieurs nœuds. Un protocole tel que la validation en deux phases peut être utilisé, 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 sur des homologues individuels. Au lieu de cela, elles sont détectées 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 d’une colonne masquée dans chaque table publiée. Cette colonne masquée stocke un ID qui combine un ID d’originateur que vous spécifiez pour chaque nœud et la version de la ligne. 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 sur les données provenant d'autres homologues. Si l’une des procédures détecte un conflit lorsqu’elle lit la valeur de colonne masquée, elle génère l’erreur 22815 ayant un niveau de gravité de 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, cette erreur entraîne l’arrêt de l’Agent de distribution d’appliquer des modifications à ce nœud. Pour plus d’informations sur la façon de gérer les conflits détectés, consultez « Gestion des conflits » plus loin dans cette rubrique.

La réplication d’égal à égal détecte les types de conflits suivants :

• Insertion

  Toutes les lignes de chaque table participant à la réplication d’égal à égal sont identifiées de manière unique à l’aide de valeurs de clé primaire. Un conflit d'insertion se produit lorsqu'une ligne avec la même valeur de clé a été insérée dans plusieurs nœuds.

• Mise à jour-mise à jour

  Se produit lorsque la même ligne a été mise à jour à plusieurs nœuds.

• Insertion-mise à jour

  Se produit si une ligne a été mise à jour à un nœud, mais que la même ligne a été supprimée, puis réinsérée sur un autre nœud.

• Insertion-suppression

  Se produit si une ligne a été supprimée à un nœud, mais que la même ligne a été supprimée, puis réinsérée sur un autre nœud.

• Update-delete

  Se produit si une ligne a été mise à jour à un nœud, mais que la même ligne a été supprimée à un autre nœud.

• Supprimer-supprimer

  Se produit lorsqu’une ligne est supprimée sur plusieurs nœuds.

Activation de la détection des conflits

Pour utiliser la détection des conflits, tous les nœuds doivent exécuter SQL Server 2008 ou une version ultérieure ; et la détection doivent être activées pour tous les nœuds. Dans SQL Server 2008 et versions ultérieures, par défaut, la détection des conflits est activée dans SQL Server Management Studio. Nous vous recommandons d’activer la détection, même dans les scénarios dans lesquels vous ne vous attendez pas à des conflits. La détection des conflits peut être activée et désactivée à l’aide de Management Studio ou de procédures stockées Transact-SQL :

• Vous pouvez activer et désactiver la détection dans Management Studio à l’aide de la page Options d’abonnement de la boîte de dialogue Propriétés de la publication ou de la page Configurer la topologie de l’Assistant Configurer la topologie d’égal à égal.

  Si vous configurez la détection des conflits à l’aide de Management Studio, l’Agent de distribution est configuré pour arrêter l’application des modifications lorsqu’un conflit est détecté.

• Vous pouvez également activer et désactiver la détection à l’aide des procédures stockées suivantes : sp_addpublication ou sp_configure_peerconflictdetection.

  Si vous configurez la détection des conflits à l’aide de procédures stockées, vous pouvez spécifier si l’Agent de distribution doit cesser d’appliquer des modifications lorsqu’un conflit est détecté. La valeur par défaut est que l’agent s’arrête. 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. Nous vous recommandons de configurer cette alerte afin que vous soyez averti lorsqu’un conflit se produit. Pour plus d’informations sur les alertes, consultez Utiliser des alertes pour les événements de l’agent de réplication.

Une fois l’Agent de distribution arrêté et l’alerte déclenchée, utilisez l’une des approches suivantes pour gérer les conflits qui se sont produits :

• Réinitialisez le nœud où 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 que les données sont dans un état cohérent.

• Essayez de synchroniser à nouveau le nœud en activant l’Agent de distribution pour continuer à appliquer les modifications :

  1. Exécutez sp_changepublication : spécifiez « p2p_continue_onconflict » pour le paramètre @property et true pour le paramètre @value.

  2. Redémarrez l’Agent de distribution.

  3. Vérifiez les conflits détectés à l’aide de la visionneuse de conflits et déterminez les lignes impliquées, le type de conflit et le gagnant. Le conflit est résolu en fonction de la valeur d’ID d’origine que vous avez spécifiée lors de la configuration : la ligne qui provient du nœud avec l’ID le plus élevé gagne le conflit. Pour plus d’informations, consultez Afficher les conflits de données pour les publications transactionnelles (SQL Server Management Studio).

  4. Exécutez la validation pour vous assurer que les lignes en conflit convergent correctement. Pour plus d’informations, consultez Validation des données répliquées.

     Remarque

     Si les données sont incohérentes après cette étape, vous devez mettre à jour manuellement les lignes sur le nœud ayant la priorité la plus élevée, puis laisser les modifications se propager à partir de ce nœud. S’il n’y a pas d’autres modifications en conflit dans la topologie, tous les nœuds sont amenés à un état cohérent.

  5. Exécutez sp_changepublication : spécifiez « p2p_continue_onconflict » pour le @property paramètre et false le @value paramètre.

Voir aussi

Réplication transactionnelle d’égal à égal