La synchronisation avec turbocompresseur

La réplication transactionnelle directionnelle peut vous apporter de nombreux avantages en termes de performances, sans que vous ayez à changer votre schéma. Toutefois, vous devez également évaluer les coûts et les inconvénients qu’elle peut engendrer. La complexité de la configuration initiale, la difficulté de la gestion des conflits et l’extensibilité limitée sont autant de facteurs à prendre soigneusement en compte avant de parvenir à la conclusion que cette solution est adaptée à votre environnement.
Complexité de la configuration. Comme la réplication transactionnelle bidirectionnelle ne s’appuie pas entièrement sur un assistant à interface graphique, vous devez créer ou modifier certains scripts de configuration de réplication manuellement et l’initialisation de l’abonné peut être ardue. Par exemple, une méthode de configuration de la réplication transactionnelle bidirectionnelle pour une base de données entre les deux serveurs de la figure 1 requiert la procédure suivante :

1. Détachez une base de données du serveur LONDRES et attachez- la au serveur LE_CAP.

2. Utilisez L’assistant Create Publication Replication Wizard pour créer une publication transactionnelle sur les serveurs LONDRES et LE_CAP.

3. Comme vous avez déjà les données que vous souhaitez répliquer, utilisez l’option no-sync sur le serveur LE_CAP lors de la souscription d’abonnement transactionnel à la publication sur le serveur LONDRES.

4. Malheureusement, lors de l’abonnement, vous ne pouvez pas ajouter le paramètre @loopback_detection = ‘true’ au moyen de l’assistant Replication Add Subscription Wizard. Par conséquent, sur le serveur LE_CAP, vous devez faire appel à l’assistant Generate Script Wizard pour générer et enregistrer le script de réplication pour l’abonnement.
Supprimez l’abonnement du serveur LE_CAP, modifiez le script de réplication que vous avez généré et enregistré, ajoutez le paramètre @loopback_detection = ‘true’ à l’appel de procédure stockée sp_addsubscription, puis exécutez le script sur le serveur LE_CAP.

5. Vous devez maintenant modifier une nouvelle fois le script de réplication, cette fois en ajoutant les noms corrects de serveur et de base de données pour le serveur LONDRES, puis exécutez le script sur ce dernier.
L’installation de la réplication transactionnelle bidirectionnelle est enfin terminée ! Et la tâche n’a pas été des plus aisées.

Gestion complexe des conflits. Le facteur suivant à prendre en compte est le sujet plutôt épineux de la gestion des conflits. Un conflit peut survenir lorsque deux serveurs modifient la même ligne, ce qui entraîne une désynchronisation des données. A la différence d’autres formes de réplication avec mise à jour d’abonnés, la réplication bidirectionnelle ne propose pas de solution standard de gestion des conflits. En fait, vous devez vous débrouiller. A contrario, la réplication de fusion fournit des fonctionnalités standard étoffées pour gérer les conflits ardus (par ex., les conflits de niveau ligne et de niveau colonne) et offre aux développeurs et aux architectes une souplesse accrue sous la forme de gestionnaires de conflits écrits en T-SQL ou dans d’autres langages de programmation. Les abonnés de la réplication avec mise à jour immédiate évitent les conflits en utilisant DTC (Distributed Transaction Coordinator) pour effectuer une validation à deux phases. Toutefois, cette technique requiert un environnement en ligne. Bien que la solution avec mise à jour en attente prenne en charge la modification des données en mode déconnecté, elle offre un modèle de gestion limité des conflits ; autrement dit, les modifications de l’abonné ou celles de l’éditeur prennent le pas sur les autres pour l’intégralité du lot de transactions. Par ailleurs, comme je l’ai mentionné précédemment, ni la réplication avec mise à jour en attente ni la solution avec mise à jour immédiate ne prennent en charge la modification du type de donnée texte ou image, contrairement à la réplication de fusion et à la réplication transactionnelle bidirectionnelle.

Cette dernière fonctionne de manière optimale lorsque vous n’escomptez pas de conflits, lorsque vous pouvez les éviter au moyen de restrictions d’application (par ex., les utilisateurs peuvent modifier les données dont ils sont propriétaires), lorsque les publications sont filtrées ou lorsqu’un seul serveur est modifié à la fois. (La dernière condition se produit le plus souvent dans un scénario de disponibilité élevée ou de basculement.) Il existe plusieurs méthodes pour éviter les conflits dans la réplication transactionnelle bidirectionnelle. De nombreuses conceptions de base de données utilisent le type de données IDENTITY comme clé primaire. Pour employer efficacement ce type de conception de tables avec la réplication transactionnelle bidirectionnelle et éviter les conflits tels que les clés en double, vous devez inclure deux étapes dans votre processus de configuration. Premièrement, vous devez définir la colonne IDENTITY avec la propriété NOT FOR REPLICATION. Deuxièmement, si la conception impose l’insertion de lignes de manière indépendante sur les deux serveurs, il est nécessaire de commencer chaque colonne IDENTITY à un nombre différent. Par exemple, vous pouvez spécifier que la table Clients sur le serveur LONDRES commence à la valeur IDENTITY 0 alors que la table Clients sur le serveur LE_CAP débutera à la valeur 1 000 000. Pour réaliser cette séparation, vous pouvez utiliser la commande DBCC CHECKIDENTRESEED directement ou la fonctionnalité sp_addscriptexec pour envoyer les commandes aux serveurs répliqués après la phase de configuration initiale et de synchronisation.

Une autre approche consiste à éviter les conflits de clé en double en concevant vos tables de telle manière qu’elles utilisent UNIQUEIDENTIFIER comme clé primaire. Mais cette méthode accroît les besoins en espace disponible et tout le monde n’apprécie pas d’avoir sur les rapports un ID client imprononçable et à rallonge du type C677EF69-8645- 4C1D-8816-7E629F8B1AA0 (qui est l’ID généré par SQL Server pour ce type de données).

Le suivi des conflits après leur survenance peut également être difficile lorsque vous employez la réplication transactionnelle bidirectionnelle. C’est particulièrement le cas des conflits de mise à jour car la dernière mise à jour d’une colonne pour une ligne supplante le résultat précédent.
Ainsi, il y aura conflit si un enregistrement est actualisé sur le serveur LONDRES, mais qu’à son arrivée sur le serveur LE_CAP, l’enregistrement a déjà été supprimé. Dans ce cas de figure, le comportement par défaut de la réplication transactionnelle est de générer une erreur et d’arrêter le traitement.
A ce stade, l’administrateur dispose de quelques options. Ainsi, il peut supprimer ou modifier l’entrée dans les tables système de réplication au niveau de la base de données de distribution, violant ainsi le commandement « Tu ne modifieras pas une table système », ou il peut réinitialiser l’abonnement.

Toutefois, en fonction de votre type de connexion, la réinitialisation peut s’avérer être une expérience déplaisante. Une autre solution consiste à réexécuter l’Agent de distribution avec le paramètre supplémentaire Skiperrors % error_ number %. Pour réduire encore les risques de conflit, vous pouvez filtrer les publications sur un champ tel que ID_région. Avec ce filtre, le serveur LONDRES publiera uniquement les données pour lesquelles ID_région=1 et le serveur LONDRES s’abonnera sur le serveur LE_CAP lequel publiera uniquement les données pour lesquelles ID_région =2.

Vous pouvez aussi utiliser l’une des méthodes non partitionnées ci-après pour suivre et gérer les conflits : en modifiant le texte ou le corps de la procédure stockée générée par la réplication afin d’inclure du code personnalisé ; en ajoutant des colonnes de suivi (par ex., des colonnes de type de données universal datetime, unique identifier ou priority) ou des déclencheurs aux tables répliquées ; en sélectionnant l’option XCALL, laquelle fournit un accès complet aux valeurs actuelles et précédentes d’un enregistrement modifié ; ou en utilisant une combinaison de ces actions. Comme vous pouvez le constater, la gestion des conflits constitue le talon d’Achille de la réplication transactionnelle bidirectionnelle.

Extensibilité limitée. Un autre facteur à prendre en compte si vous envisagez d’utiliser la réplication transactionnelle bidirectionnelle est le fait de savoir si vous allez étendre la conception bidirectionnelle afin d’inclure plus de deux serveurs. L’ajout de filtres aux publications pour le partitionnement peut étendre la réplication bidirectionnelle à plusieurs serveurs.
Toutefois, cette approche peut accroître sensiblement la complexité, les coûts d’administration, voire les risques de dégradation des performances.
Celles-ci sont fortement dépendantes de la complexité du filtre. Pour des performances et une prise en charge optimales, vous devez concevoir votre système de réplication de telle sorte qu’il comporte toujours un seul hub central et que les communications ne fassent pas intervenir plus de deux serveurs. Par exemple, comme l’illustre la figure 2, le serveur LONDRES peut effectuer une réplication bidirectionnelle avec le serveur LE_CAP et le serveur NEW_YORK, mais ces deux derniers serveurs ne peuvent pas exécuter directement une réplication l’un avec l’autre. Dans cet exemple de conception non filtrée, les modifications seront diffusées sur tous les serveurs : ainsi, les modifications sur le serveur LE_CAP arriveront au final sur NEW_YORK, mais elles passeront systématiquement par le serveur général LONDRES. Si nécessaire, vous pouvez mettre en oeuvre des règles métier simples dans votre application utilisateur, afin de limiter les modifications aux lignes d’un site ou d’un serveur spécifiques. Cette conception est avantageuse pour les applications qui permettent aux utilisateurs de parcourir toutes les données mais de modifier uniquement les enregistrements locaux. Toutefois, si les utilisateurs accomplissent fréquemment de nombreuses modifications sur chaque serveur, l’extension horizontale de cette approche non filtrée peut constituer un véritable défi car le nombre élevé de transactions échangées entre les serveurs peut accroître la charge au niveau des performances du réseau.