> Data > La synchronisation avec turbocompresseur

La synchronisation avec turbocompresseur

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Bren Newman - Mis en ligne le 19/04/2006 - Publié en Février 2005

La gestion d’un système de base de données distribué présente de nombreux défis, dont l’un des plus ardus est le besoin de synchroniser rapidement les mises à jour. La réplication transactionnelle et la réplication de fusion sont des techniques de réplication efficaces bien connues. Mais chacune comporte des limitations et peut restreindre les performances. Si vous éprouvez de la frustration par rapport aux limitations de ces méthodes, vous oubliez peut-être une autre solution : la réplication transactionnelle bidirectionnelle. Dans certains cas, la mise en oeuvre de cette technique procure une solution particulièrement rapide pour la mise à jour de plusieurs sites géographiquement disséminés. Si vous êtes prêt à franchir un certain nombre d’obstacles, l’équipe Microsoft de consultants clients pour le développement SQL Server aide les clients à mettre en place la réplication bidirectionnelle entre autres sur les marchés de la finance, de la bourse et des télécommunications. La plupart de ces clients utilisent cette technologie afin de créer une solution de reporting de base de données qu’ils peuvent convertir rapidement et facilement en site de basculement ou de reprise après sinistre.SQL Server prend en charge cette forme puissante et rapide de réplication transactionnelle depuis la version 7.0. Toutefois, peu d’administrateurs de base de données (DBA) ont connaissance de cette fonctionnalité ou savent exploiter sa puissance, dans une large mesure en raison d’une documentation inappropriée et d’un manque général de compréhension de son fonctionnement. La documentation en ligne de SQL Server 7.0 inclut une section particulièrement réduite sur le sujet et Microsoft a malheureusement omis de traiter cet aspect dans les premières éditions de la documentation en ligne de SQL Server 2000. Depuis, la société de Redmond s’est rattrapée dans la dernière édition de cette documentation, téléchargeable à l’adresse http://www. microsoft.com/sql/techinfo/ productdoc/2000/books.asp.

Le tableau Web 1 (téléchargeable à l’adresse http://www. itpro.fr, Club abonnés) compare les fonctionnalités de quatre méthodes de réplication : la réplication transactionnelle bidirectionnelle, la réplication transactionnelle avec mise à jour en attente, la réplication transactionnelle avec mise à jour immédiate et la réplication de fusion. La majorité des DBA ont recours à la réplication transactionnelle afin de disséminer un flux de transactions journalisées d’une source, l’éditeur (Publisher), vers un ou plusieurs serveurs cible non actualisés et fortement utilisés pour les opérations de lecture (par ex., les serveurs de reporting), appelés abonnés (Subscriber). Les DBA utilisent en général ce type de réplication afin d’augmenter les performances des lectures agrégées. Les abonnements à mise à jour immédiate, introduits par Microsoft dans SQL Server 7.0, permettent aux abonnés de la réplication transactionnelle de modifier les données à leur niveau. Toutefois, ces derniers ne peuvent effectuer cette modification que via une connexion réseau avec l’éditeur (autrement dit, l’abonné doit être en ligne). Dans SQL Server 2000, les abonnés avec mise à jour en attente peuvent modifier les données à leur niveau sans être connectés à l’éditeur. Ces deux méthodes nécessitent l’ajout d’une colonne aux tables utilisateur.
Par ailleurs, elles ne prennent pas en charge la mise à jour de colonnes de texte ou d’images et assurent le suivi des modifications au moyen de déclencheurs générés automatiquement.
Bien que la réplication de fusion (introduite dans SQL Server 7.0) gère la modification des colonnes de texte et d’images, elle utilise aussi des déclencheurs et impose d’ajouter aux tables une colonne spécifique à la réplication et contenant le type de données uniqueidentifier (par ex., un GUID), qui ajoute 16 octets supplémentaires et est globalement unique.
L’ajout de ces déclencheurs et colonnes peut se révéler problématique pour certaines applications et nombre de DBA rechigne à l’employer. Microsoft a mis au point la réplication de fusion spécialement à l’attention des utilisateurs mobiles déconnectés (par ex., les utilisateurs d’applications d’automatisation de la force de vente), proposant des possibilités extensibles de gestion et de suivi des modifications et des conflits, ainsi que des fonctionnalités extrêmement flexibles de partitionnement et de filtrage. Toutefois, pour tirer parti de ces avantages, vous devez vous acc

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.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Data - Par iTPro.fr - Publié le 24 juin 2010