par Sameer Dandage - Mis en ligne le 6/07/2005 - Publié en Octobre 2004
Si une légère attente n'est pas critique, la solution de réplication TRQU est faite
pour vous
Aujourd'hui, de plus en plus d'entreprises doivent rendre leurs données disponibles
sur de multiples serveurs et sur des sites distants, en préservant une synchronisation
la plus étroite possible entre les données de chacun des sites. Dès
lors qu'il existe plusieurs copies des données stratégiques, la disponibilité de ces
dernières s'en trouve améliorée. Par exemple, en cas de défaillance d'un site, vous
pouvez dévier le trafic vers un autre site ou serveur ...Par ailleurs, les administrateurs
de base de données (DBA) peuvent répartir la charge sur plusieurs serveurs,
afin d'éviter la surcharge de l'un deux et améliorer les temps de réponse aux requêtes
des utilisateurs, en particulier si le serveur est situé à proximité de ceux-ci.
Envisageons quelques instants un scénario illustrant les besoins de failover et
de répartition de la charge pour un système de base de données qui inclut une application
à trois niveaux sur deux sites géographiquement
distincts. Chaque site utilise un
serveur Web, un serveur d'applications et un
serveur de base de données. Lorsque le fonctionnement
du système est optimum, le serveur
Web et le serveur d'applications de
chaque site distribuent leurs requêtes utilisateur
entre les deux serveurs de base de données
afin qu'ils puissent se répartir la charge
de travail. Toutefois, en cas d'indisponibilité
d'un des deux serveurs de base de données ou
d'une des bases de données, les serveurs Web
et d'applications peuvent basculer toutes leurs requêtes vers le serveur de base de
données de l'autre site. Dès que le premier serveur de base de données est de
nouveau opérationnel, le processus de répartition des requêtes utilisateur entre
les deux est rétabli.
Lorsqu'une organisation utilise un site actif et maintient l'autre en lecture
seule, les tâches du DBA sont relativement simples. En revanche, son travail devient
très vite complexe si l'organisation décide de placer plusieurs sites en mode
actif et de synchroniser les données entre eux. Pour répondre à ce cas de figure,
SQL Server propose une option : la réplication transactionnelle. L'objet de cet article
n'étant pas d'expliquer les fondements de ce mécanisme, vous trouverez plus
d'informations sur le sujet en lisant la rubrique « Réplication transactionnelle » de
la documentation en ligne de SQL Server.
SQL Server 2000 propose deux options de réplication transactionnelle permettant
d'actualiser les données au niveau de l'abonné (Subscriber). Pour la première,
intitulée « Réplication transactionnelle avec mise à jour immédiate des
Subscribers », SQL Server utilise une validation à deux phases afin de mettre à jour
simultanément dans la même transaction l'éditeur (Publisher) et le Subscriber. La
validation à deux phases verrouille la ligne concernée sur tous les sites participant à la réplication lorsqu'une mise à jour est effectuée sur l'un
d'eux. Ce mécanisme de verrouillage élimine toute latence
entre le moment où un Subscriber est mis à jour et le moment
où le Publisher reflète la mise à jour en question. Pour
que cette option fonctionne, le Publisher et le Subscriber
doivent toutefois être en cours d'exécution et connectés en
permanence, faute de quoi les utilisateurs ne peuvent pas effectuer
de mises à jour sur le Subscriber.
La deuxième option est la « Réplication transactionnelle
avec mises à jour en file d'attente », que j'abrégerai en TRQU
(Transactional Replication with Queued Updates) dans cet
article. A la différence de la première option, la solution
TRQU requiert une certaine latence entre le moment d'une
mise à jour sur le Subscriber et le moment où celle-ci est répercutée
sur le Publisher. Mais cette approche présente un
inconvénient : une ligne peut être mise à jour avec des données
différentes sur plusieurs sites simultanément et la cohérence
des données entre les sites ne sera pas assurée tant
qu'un mécanisme de résolution des conflits n'aura pas
éliminé cette incohérence. Vous définissez des règles de
résolution, telles que « l'éditeur gagne » (Publisher wins) ou
« l'abonné gagne » (Subscriber wins), dans la configuration
TRQU. En conséquence de quoi, les mises à jour sur un site
peuvent remplacer celles effectuées sur un autre. L'approche
TRQU présente l'avantage suivant : le Publisher et le
Subscriber ne doivent pas être connectés en permanence
et le Publisher peut être arrêté pendant la mise à jour d'un
Subscriber. Par conséquent, la réplication TRQU garantit aux
utilisateurs une disponibilité plus élevée d
Les files d’attente
![Les files d’attente Les files d’attente](https://www.itpro.fr/wp-content/uploads/2014/05/9a38920c499c487b8e5dab487ae5a501.jpg)
Le processus de configuration de TRQU incluant plus de 40
écrans, je ne vais pas tous les présenter dans cet article. Je
vais plutôt énumérer les différentes étapes du processus et fournir des captures d’écran correspondant aux étapes clés
afin que vous puissiez vous repérer.
La configuration de la réplication TRQU se subdivise en
trois étapes. La première consiste à configurer le distributeur
(Distributor), le nom et l’emplacement de la base de données
de distribution, le dossier de capture instantanée, le
Publisher et le Subscriber, puis à activer la base de données
de publication. En règle générale, vous effectuez cette étape
sur le Distributor. Au cours de l’étape 2, vous configurez la
publication et les articles qu’elle contient. Cette étape s’effectue
généralement sur le Publisher. Enfin, l’étape 3 sert à
configurer l’envoi d’abonnement (Push Subscription) qui inclut
la publication définie à l’étape 2, ainsi qu’un Subscriber
et la base de données d’abonnement à laquelle vous enverrez
la publication. Cette étape est effectuée habituellement
sur le Publisher. Pour les besoins de cet article, j’utilise une
approche Push Subscription pour répliquer la table authors
de la base de données Pubs vers une table du même nom
dans la base de données Northwind.
Téléchargez cette ressource
![Guide de technologie 5G pour l’entreprise](https://www.itpro.fr/wp-content/uploads/2024/04/Livre-blanc-The-Big-Book-of-Enterprise-5G-Cradlepoint-Groupe-Ericsson-4G-LTE-et-5G-WAN-Experts-2024.png)
Guide de technologie 5G pour l’entreprise
Le livre blanc "The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.
Les articles les plus consultés
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- Intelligence Artificielle : DeepKube sécurise en profondeur les données des entreprises
- Les projets d’intégration augmentent la charge de travail des services IT
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- La blockchain en pratique
Les plus consultés sur iTPro.fr
- Impact de l’IA générative sur le lieu de travail
- Red Sift : une proposition clé pour sécuriser le patrimoine numérique
- Cloud Temple : le cloud de confiance de référence du marché français et européen
- Fusion d’identités avec Binary Tree Directory Sync Pro
- Contrôler et optimiser les dépenses informatiques dans le contexte macroéconomique actuel
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)