Réplication transactionnelle d'égal à égal

Mis à jour : 12 décembre 2006

La réplication transactionnelle d'égal à égal est destinée aux applications qui sont susceptibles de lire ou de modifier les données de n'importe quelle base de données participant à la réplication. Par exemple, une application marchande en ligne convient très bien à la réplication d'égal à égal : les performances de l'application sont optimisées grâce à la répartition des requêtes qui lisent des données dans plusieurs bases de données. En outre, si l'un des serveurs hébergeant les bases de données n'est pas disponible, une application peut être programmée pour router le trafic vers les serveurs restants qui contiennent des copies identiques des données. Les performances de lecture sont améliorées car l'activité peut être répartie sur tous les nœuds. Les performances de l'agrégation des mises à jour, insertions et suppressions pour la topologie sont semblables à celles d'un nœud unique car en fin de compte, toutes les modifications sont propagées sur tous les nœuds.

Tous les nœuds d'une topologie d'égal à égal sont des homologues : chaque nœud publie et s'abonne au même schéma et aux mêmes données. Les modifications (insertions, mises à jour et suppressions) peuvent s'effectuer sur tous les nœuds. La réplication reconnaît à quel moment une modification a été appliquée à un nœud donné, empêchant ainsi les modifications de boucler plusieurs fois dans les nœuds.

Remarque :

Les applications personnalisées qui accèdent aux données et les modifient doivent s'assurer que les insertions, mises à jour et suppressions sont partitionnées, de telle sorte que les modifications apportées à une ligne précise issue d'un nœud unique soient synchronisées avec toutes les autres bases de données de la topologie avant qu'un autre nœud ne modifie la ligne. Si une application apporte des modifications simultanées conflictuelles à une ligne précise sur plusieurs nœuds, utilisez la réplication de fusion qui convient bien à la gestion des conflits. Pour plus d'informations sur la réplication de fusion, consultez Présentation de la réplication de fusion.

La réplication transactionnelle standard suppose que les Abonnés sont en lecture seule et que leur structure est hiérarchique : en général, un serveur de publication publie des données sur un ou plusieurs Abonnés. La réplication transactionnelle standard prend également en charge une structure de republication : les mises à jour sont remises d'un serveur de publication à un ensemble d'Abonnés de republication qui, à leur tour, remettent les mises à jour à un ensemble final d'Abonnés des nœuds inférieurs. Les abonnements de mise à jour permettent aux Abonnés de renvoyer des modifications de données (push) au serveur de publication, mais l'organisation reste hiérarchique car les modifications respectent cette structure lors du déplacement entre les Abonnés et les serveurs de publication. Contrairement à la réplication transactionnelle en lecture seule et à la réplication transactionnelle avec abonnements de mise à jour, les relations entre les nœuds d'une topologie de réplication d'égal à égal sont des relations d'homologues plutôt que des relations hiérarchiques, dont chaque nœud contient un schéma et des données identiques.

Remarque :

S'il est possible d'effectuer des mises à jour dans plusieurs bases de données participantes, il est important de comprendre que les topologies d'égal à égal ne requièrent ni n'autorisent les options de mise à jour immédiate ou en file d'attente des publications. Pour plus d'informations sur la mise à jour immédiate et en file d'attente, consultez Abonnements pouvant être mis à jour pour la réplication transactionnelle.

Topologies d'égal à égal

Les scénarios suivants illustrent des utilisations standard de la réplication d'égal à égal.

Topologie comprenant deux bases de données participantes

Les illustrations ci-dessus montrent deux bases de données participantes dont le trafic utilisateur est acheminé vers les bases de données par le biais d'un serveur d'applications. Cette configuration peut s'appliquer à de nombreuses applications (allant des sites Web aux applications de groupe de travail) et présente les avantages suivants :

• amélioration des performances de lecture due à la répartition des lectures sur les deux serveurs ;
• disponibilité plus élevée si la maintenance est requise ou en cas de panne sur un nœud.

Dans les deux illustrations, l'activité de lecture est équilibrée entre les bases de données participantes, mais les mises à jour sont gérées autrement :

• À gauche, les mises à jour sont partitionnées entre les deux serveurs ; si la base de données contenait un catalogue de produits, une application personnalisée pourrait, par exemple, envoyer au nœud A les mises à jour des produits dont le nom commence par les lettres A à M et au nœud B les mises à jour des produits dont le nom commence par les lettres N à Z. Les mises à jour sont ensuites répliquées sur l'autre nœud.
• À droite, toutes les mises à jour sont envoyées au nœud B. À ce stade, les mises à jour sont répliquées sur le nœud A. Si le nœud B est hors connexion (pour des opérations de maintenance, par exemple), le serveur d'applications peut envoyer toutes les activités sur le nœud A. Lorsque le nœud B revient en ligne, il peut à nouveau recevoir les mises à jour ; le serveur d'applications peut alors les lui transférer ou continuer à les envoyer au nœud A.

Si la réplication d'égal à égal prend en charge les deux méthodes, l'exemple de mise à jour centralisée à droite est également souvent utilisé avec la réplication transactionnelle standard.

Topologie comprenant au moins trois bases de données participantes

L'illustration ci-dessus montre trois bases de données participantes qui servent de dorsales à une entreprise internationale d'assistance technique de logiciels dont les bureaux se trouvent à Los Angeles, Londres et Taipei. Les ingénieurs de support enregistrent les appels clients dans chaque bureau et ils entrent et mettent à jour les informations sur chaque appel client. Comme les fuseaux horaires des trois bureaux ont huit heures d'écart, il n'y a pas de chevauchement pendant une journée de travail : lorsque le bureau de Taipei ferme, le bureau de Londres ouvre. Si un appel n'est pas terminé à la fermeture d'un bureau, il est transféré à un conseiller client dans un autre bureau qui ouvre.

Chaque bureau possède un serveur de base de données et un serveur d'applications dont se servent les ingénieurs de support lorsqu'ils entrent et mettent à jour les informations sur les appels clients. Comme la topologie est partitionnée selon l'horaire, les mises à jour n'ont lieu que sur le nœud ouvert pendant les heures de bureau ; les mises à jour sont ensuite acheminées aux autres bases de données participantes. Cette topologie présente les avantages suivants :

• indépendance sans isolement : chaque bureau peut insérer, mettre à jour ou supprimer des données en toute autonomie tout en pouvant les partager du fait de leur réplication sur toutes les bases de données participantes ;
• disponibilité élevée en cas de panne ou de maintenance sur une base de données participante quelconque.
  

L'illustration ci-dessus montre l'ajout d'un nœud dans la topologie qui en compte déjà trois. Un nœud pourrait être ajouté dans ce scénario :

• parce qu'un autre bureau est ouvert ;
• pour fournir une disponibilité élevée afin de prendre en charge la maintenance ou augmenter la tolérance de panne en cas de gros problème.
• Notez que dans les topologies à trois et à quatre nœuds, toutes les bases de données publient sur toutes les autres et s'y abonnent, fournissant ainsi une disponibilité maximale en cas de maintenance ou de panne d'un ou de plusieurs nœuds. Lors de l'ajout de nœuds, veillez à équilibrer les besoins en disponibilité et en évolutivité par rapport aux performances et à la complexité du déploiement et de l'administration.

Configuration d'une réplication d'égal à égal

La configuration d'une topologie de réplication d'égal à égal est très semblable à celle d'une série de publications et d'abonnements transactionnels standard. Les étapes décrites dans la rubrique ci-après montrent la configuration d'un système à trois nœuds, très semblable à la configuration illustrée dans le diagramme ci-dessus à gauche.

Pour configurer la réplication d'égal à égal

• SQL Server Management Studio: Procédure : configurer la réplication transactionnelle d'égal à égal (SQL Server Management Studio)
• Programmation Transact-SQL de la réplication : How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)

Considérations sur l'utilisation de la réplication d'égal à égal

Lorsque vous utilisez la réplication d'égal à égal, gardez à l'esprit les points suivants :

Considérations générales

• La réplication d'égal à égal est disponible uniquement dans SQL Server 2005 Enterprise Edition.
• Toutes les bases de données participantes doivent contenir un schéma et des données identiques :
  • Les noms des objets, le schéma des objets et les noms des publications doivent être identiques entre les bases de données participantes.
  • Les publications doivent permettre la réplication des modifications de schéma (valeur 1 pour la propriété de publication replicate_ddl, soit la valeur par défaut). Pour plus d'informations, consultez Modification du schéma dans les bases de données de publication.
  • Le filtrage des lignes et des colonnes n'est pas pris en charge.
• Il est recommandé que chaque nœud utilise sa propre base de données de distribution afin d'éviter le risque d'avoir un point d'échec unique.
• Les tables et autres objets ne peuvent pas être inclus dans plusieurs publications d'égal à égal au sein d'une base de données de publication unique.
• Une publication doit être activée pour la réplication d'égal à égal avant la création des abonnements.
• Les abonnements doivent être initialisés à l'aide d'une sauvegarde ou de l'option Prise en charge de la réplication uniquement. Pour plus d'informations, consultez Initialisation d'un abonnement transactionnel sans capture instantanée.
• La détection et la résolution des conflits ne sont pas fournies. Les mises à jour pour une ligne spécifique doivent être effectuées sur une base de données unique jusqu'à ce que celle-ci soit synchronisée avec ses homologues. Cette opération peut être réalisée, par exemple, par l'application qui envoie les mises à jour concernant un ensemble de lignes à un nœud particulier.
• L'utilisation des colonnes d'identité est déconseillée. Avec les identités, vous devez gérer manuellement les plages affectées aux tables sur chaque base de données participante. Pour plus d'informations, consultez la section « Affectation de plages pour la gestion manuelle de plages d'identité » de la rubrique Réplication de colonnes d'identité.

Restrictions liées aux fonctionnalités

La réplication d'égal à égal prend en charge les fonctionnalités principales de la réplication transactionnelle. Les options suivantes ne sont pas prises en charge :

• initialisation et réinitialisation avec capture instantanée ;
• filtres de lignes et de colonnes ;
• colonnes d'horodatage ;
• serveurs de publication et Abonnés non-SQL Server ;
• abonnements mis à jour immédiatement ou en attente ;
• abonnements anonymes ;
• abonnements partiels ;
• abonnements pouvant être attachés et abonnements transformables (tous désapprouvés dans SQL Server 2005) ;
• Agents de distribution partagés ;
• paramètre de l'Agent de Distribution -SubscriptionStreams et paramètre de l'Agent de lecture du journal -MaxCmdsInTran ;
• propriétés d'article @destination_owner et @destination_table.

Les propriétés suivantes présentent des considérations spéciales :

• la propriété de publication @allow_initialize_from_backup requiert une valeur 'true' ;
• la propriété d'article @replicate_ddl requiert une valeur 'true', @identityrangemanagementoption requiert une valeur 'manual' et @status requiert que l'option '24' soit définie ;
• la valeur des propriétés d'article @ins_cmd, @del_cmd et @upd_cmd ne peut pas être définie sur 'SQL' ;
• la propriété d'abonnement @sync_type requiert la valeur 'none' ou 'automatic' ;

Considérations sur la maintenance

• Les opérations suivantes nécessitent la suspension du système (arrêt de l'activité sur les tables publiées de tous les nœuds et vérification que chaque nœud a reçu l'ensemble des modifications provenant de tous les autres nœuds) :
  • ajout d'un nœud à une topologie existante ;
  • ajout d'un article à une publication existante ;
  • modification du schéma ;
  • restauration d'un nœud à partir d'une sauvegarde.
    Pour plus d'informations, consultez Procédure : configurer la réplication transactionnelle d'égal à égal (SQL Server Management Studio), How to: Quiesce a Replication Topology (Replication Transact-SQL Programming) et How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).
• Si vous ajoutez un nouveau nœud dans une topologie d'égal à égal, vous devez effectuer une restauration uniquement à partir des sauvegardes créées après l'ajout du nouveau nœud. Pour plus d'informations, consultez Procédure : configurer la réplication transactionnelle d'égal à égal (SQL Server Management Studio).
• Il n'est pas possible de réinitialiser les abonnements dans une topologie d'égal à égal. Si vous devez vérifier qu'un nœud possède une nouvelle copie des données, restaurez une sauvegarde sur le nœud.

Historique des modifications

Version	Historique
12 décembre 2006	Contenu modifié : Ajout d'une instruction explicite indiquant que cette fonctionnalité est disponible uniquement dans SQL Server 2005 Enterprise Edition.
17 juillet 2006	Contenu modifié : Informations mises à jour sur les fonctionnalités de réplication transactionnelle pouvant être utilisées dans le cadre de la réplication d'égal à égal.

Voir aussi

Concepts

Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée
Types de publication pour la réplication transactionnelle

Autres ressources

How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)

Aide et Informations

Assistance sur SQL Server 2005