La réplication permet d'offrir les données où et quand elles
sont nécessaires. Elle est particulièrement utile dans les scénarios
suivants:
- Epauler une force de ventes mobile déconnectée
- Maintenir un serveur en « warm-standby », en secours
- Maintenir un serveur OLAP (online analytical processing)
- Agréger les
ventes provenant de serveurs distribués dans
l’entreprise, dans une seule base de données
A partir d’une base de données, se déployer vers plusieurs
serveurs de bases de données du e-Commerce
On distingue trois types principaux de réplication: par instantané,
transactionnelle et par fusion. Chacun d’eux applique
divers degrés de latence des données : des mises à jour en
temps réel aux modes offline ou déconnectés. La réplication
par instantané, le genre le plus simple, consiste à capturer une
vue instantanée d’une publication comme un instantané des
données et à le transférer vers l’abonné (Subscriber). La réplication
par instantané est intéressante quand les données sont
relativement statiques ou quand une haute latence est acceptable.
On utilise aussi la réplication par instantané pour fournir
les données initiales aux deux autres modes de réplication: par
fusion et transactionnelle.
La réplication transactionnelle commence par un instantané
des données de publication que l’on veut transférer vers le
Subscriber. A partir de là , la réplication envoie au fur et à mesure
les changements au Subscriber. Bien qu’on utilise généralement
la réplication transactionnelle pour la transmission du
Publisher vers le Subscriber, il est également possible de propager
les mises à jour effectuées chez le Subscriber vers le
Publisher – c’est ce qu’on appelle des abonnements actualisables.
Le processus de réplication peut même mettre ces
changements de Subscriber en file d’attente en cas d’interruption
de la connexion. Toutefois, si l’on a affaire à un scénario
dans lequel les utilisateurs apportent beaucoup de modifications
aux données chez le Subscriber ou dans lequel le
Subscriber sera déconnecté pendant une longue durée, il vaut
mieux se tourner vers la réplication par fusion.
Dans la réplication par fusion, les utilisateurs peuvent librement
modifier les données publiées aussi bien chez le
Publisher que chez le Subscriber, même en mode entièrement
déconnecté. Quand la connexion entre le Publisher et le
Subscriber est établie, la réplication par fusion transfère les
changements du Subscriber vers le Publisher, utilise des règles
prédéfinies pour résoudre les éventuels changements du
Subscriber qui seraient en conflit avec ceux effectués chez le
Publisher, et transfère en aval les changements du Publisher (y
compris les éventuels conflits résolus) vers le Subscriber. C’est
ce qu’on appelle la synchronisation. La réplication par fusion
supporte également SQL Server 2000 Windows CE Edition
Subscribers, ce qui en fait la solution idéale pour répliquer des
données sur des appareils portatifs.
La réplication de SQL Server est effectuée par un ensemble de
tables de système de réplication chez le Publisher et le
Distributor (et chez le Subscriber, dans le cas de réplication par
fusion), un groupe de procédures stockées du système de réplication
et un groupe d’agents de réplication. Ces agents, que
le SQL Server Agent peut héberger et planifier, gèrent le flux
des données de réplication et assument la fonction de réplication.
Les principaux agents de réplication sont les suivants:
- Snapshot Agent. Cet agent, qui intervient dans tous les types
de réplication, fonctionne chez le Distributor et gère l’instantané
des données.
- Log Reader Agent. En réplication transactionnelle, chaque
base de données de publication a son propre Log Reader
Agent, qui fonctionne chez le Distributor et lit les données
provenant du journal sur la base de données de publication.
- Distribution Agent. Cet agent, utilisé dans la réplication par
instantané et transactionnelle, fonctionne soit chez le
Distributor soit chez le Subscriber et est chargé de transférer
les données du Distributor vers le Subscriber.
- Merge Agent. Il fonctionne chez le Distributor ou chez le
Subscriber pour appliquer l’instantané initial chez le
Subscriber. Après quoi il transfère et rapproche tous les changements
de données pendant une synchronisation de fusion.
Le comportement des agents Distribution et Merge
dépend aussi du genre d’abonnements qu’ils gèrent. La réplication
a deux types principaux d’abonnements: abonnements
pull, qui sont gérés par le Subscriber, et abonnement push, gérés
par le Distributor. Pour les abonnements push, ces agents
fonctionnent sur le Distributor et le Publisher/Distributor gère
le comportement des agents. Pour des abonnements pull, les
agents fonctionnent chez le Subscriber. Les abonnements pull
anonymes sont un type spécial d’abonnement pull dans lequel
le Publisher n’a pas besoin de maintenir le jeu complet de
métadonnées concernant les Subscribers.
Vous pouvez superviser tous ces agents au moyen du composant
Replication Monitor de Enterprise Manager. En outre, vous
pouvez accéder à la plupart de leurs fonctionnalités par programme,
en utilisant des procédures stockées de réplication ou
des utilitaires ligne de commande, ou encore en utilisant des
contrôles de réplication ActiveX, comme on le voit dans l’article
principal. Pour plus d’informations sur la programmation de la
réplication et sur la réplication SQL Server en général, voir la
masse d’informations qui se trouvent dans SQL Server 2000
Books Online (BOL).
Téléchargez cette ressource
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.