III.3. DEFINITION
En informatique, la réplication est un processus de
partage d'informations pour assurer la cohérence de données entre
plusieurs sources de données redondantes, pour améliorer la
fiabilité, la tolérance aux pannes ou l'accessibilité.
On parle de réplication de données si les
mêmes données sont dupliquées sur plusieurs
périphériques. Une application de base de données repose
sur un modèle client-serveur. Dans ce modèle, le client se
connecte au SGBD pour passer des ordres. Ces ordres sont de deux natures :
lecture (on parle alors de requêtes) ou mise
à jour (on parle alors de transactions). Pour les transactions,
il y a une modification des données sur le serveur, mais cela reste des
ordres de courte durée.
A l'inverse, dans le cas d'une lecture, il n'y a pas de
modification des données mais les traitements peuvent être longs
et porter sur une grande masse de données. On comprend donc
aisément que, dans le cadre d'un site web par exemple, un nombre
important de requêtes peut surcharger partiellement (ou
complètement) le serveur. Il existe plusieurs solutions pour
remédier à ce genre de problèmes et, ça tombe bien,
la réplication en est une.
La réplication n'est pas à confondre avec une
sauvegarde : les données sauvegardées ne changent pas dans le
temps, reflétant un état fixe des données, tandis que les
données répliquées évoluent sans cesse à
mesure que les données sources changent.
La réplication est aussi considérée comme
la capacité à maintenir à jour une base de données
distribuée sur plusieurs machines reliées en réseau, en
recopiant à intervalles réguliers des morceaux ou
l'intégralité de la base d'une machine à l'autre.
Plusieurs méthodes de réplication existent selon la configuration
matérielle présente.
III.4. PRINCIPES DE LA
REPLICATION
L'objectif principal de la réplication est de faciliter
l'accès aux données en augmentant la disponibilité. Soit
parce que les données sont copiées sur différents sites
permettant de répartir les requêtes, soit parce qu'un site peut
prendre la relève lorsque le serveur principal s'écroule.
Une autre application tout aussi importante est la
synchronisation des systèmes embarqués non connectés en
permanence. Ce qui peut se résumer à l'aide des trois types de
scénario suivants :
ü Deux serveurs distants sur lesquels les données
doivent être consistantes ;
ü Deux serveurs, un comme serveur principal, l'autre
comme serveur de backup à chaud ;
ü Plusieurs serveurs en cluster utilisés pour de
l'équilibrage de charge et de la tolérance à la panne.
Le principe de la réplication, qui met en jeu au
minimum deux SGBD, est assez simple et se déroule en trois temps :
· La base « maître » reçoit un
ordre de mise à jour (INSERT, UPDATE ou DELETE).
· Les modifications faites sur les données sont
détectées et stockées (dans une table, un fichier, une
queue) en vue de leur propagation.
· Un processus de réplication prend en charge la
propagation des modifications à faire sur une seconde base dite esclave.
Il peut bien entendu y avoir plus d'une base esclave.
Bien entendu, il est tout à fait possible de faire de
la réplication dans les deux sens (de l'esclave vers le maître et
inversement). On parlera dans ce cas-là de réplication
bidirectionnelle ou symétrique.
Dans le cas contraire la réplication est
unidirectionnelle (seulement du maître vers l'esclave) et on parle de
réplication en lecture seule ou asymétrique.
De plus, la réplication peut être faite de
manière synchrone ou asynchrone. Dans le premier cas, la
résolution des conflits éventuels entre deux sites intervient
avant la validation des transactions ; Dans le second cas, la résolution
est faite dans des transactions séparées. Il est donc possible
d'avoir quatre modèles de réplication :
ü Réplication asymétrique avec propagation
asynchrone ;
ü Réplication asymétrique avec propagation
synchrone ;
ü Réplication symétrique avec propagation
asynchrone ;
ü Réplication symétrique avec propagation
synchrone.
Mise à jour synchrone et asynchrone
Jusque-là, nous avons supposé que toute mise
à jour de la base demandée depuis un noeud était
effectuée en temps réel sur les autres noeuds,
c'est-à-dire pour le compte de la même transaction atomique. Ceci
correspond au mode de mise à jour synchrone qui s'avère souvent
trop contraignant pour les applications.
Mise à jour synchrone
C'est le mode de distribution dans lequel toutes les sous
opérations locales effectuées suite à une mise à
jour globale sont accomplies pour le compte de la même transaction.
Dans le contexte des copies, ce mode de distribution est
très utile lorsque les mises à jour effectuées sur un site
doivent être prises en compte immédiatement sur les autres sites.
L'avantage essentiel de la mise à jour synchrone est de
garder toutes les données au dernier niveau de mise à jour. Le
système peut alors garantir la fourniture de la dernière version
des données quel que soit la copie accédée.
Les inconvénients sont cependant multiples, ce qui
conduit beaucoup d'application à éviter la gestion de copies
synchrones. Ce sont d'une part, la nécessité de gérer des
transactions multiples coûteuses en ressources et d'autre part, la
complexité des algorithmes de gestion de concurrence et de panne d'un
site. C'est pour cela que l'on préfère souvent le mode de mise
à jour asynchrone (encore appelé mise à jour
différée)
Mise à jour asynchrone
C'est le mode de distribution dans lequel certaines sous
opérations locales effectuées suite à une mise à
jour globale sont accomplies dans des transactions indépendantes en
temps différé. Le temps de mise à jour des copies peut
être plus au moins différé : les transactions de
report peuvent être lancées dès que possible ou à
des instants fixes, par exemple le soir ou en fin de semaine.
Les avantages sont la possibilité de mettre à
jour en temps choisi des données, tout en autorisant l'accès aux
versions anciennes avant la mise à niveau.
Les inconvénients sont bien sûr que
l'accès à la dernière version n'est pas garanti. Ce qui
limite les possibilités des mises à jour.
Technique de diffusion des mises à
jour
La diffusion automatique des mises à jour
appliquée à une copie aux autres copies doit être
assurée par le SGBD réparti. Plusieurs techniques de diffusion
sont possibles parmi lesquelles, on distinguera celles basées sur la
diffusion de l'opération de mise à jour, de celles basées
sur la diffusion du résultat de l'opération.
Diffuser le résultat présente l'avantage de ne
pas devoir ré exécuter l'opération sur le site de la
copie, mais l'inconvénient de nécessité un ordonnancement
identique des mises à jour en tous les sites afin d'éviter les
pertes de mises à jour. Le report d'opération est plus flexible,
notamment dans le cas d'opérations commutatives.
Réplication asymétrique
C'est une technique de gestion de copie basée sur un
site primaire seul autorisé à mettre à jour et
chargé de diffuser les mises à jour aux autres copies dites
secondaire. Le site primaire effectue les contrôles et garantit
l'ordonnancement correct des mises à jour.
A noter que le choix d'une technique asymétrique est
orthogonal au choix d'un mode de diffusion synchrone ou asynchrone des mises
à jour et on peut donc distinguer l'asymétrique synchrone et
l'asymétrique asynchrone.
SITES SECONDAIRES
SITE PRIMAIRE
La première technique est illustrée Fig. 3.1
où un site primaire pousse les mises à jour en temps réel
vers deux sites secondaires. La deuxième est illustrée Fig. 3.2
cette fois, les mises à jour sont poussées en temps
différé via une file persistante. Dans les deux cas, de
problèmes surviennent lorsque le site primaire tombe en panne.
Figure 3.1. Réplication Asymétrique Synchrone
SITES SECONDAIRES
SITE PRIMAIRE
Ici, toute mise à jour est d'abord appliquée au
site maître puis diffusée à temps réel aux sites
secondaires.
Figure 3.2. Réplication Asymétrique Asynchrone
Par contre ici, la mise à jour se s'effectue d'abord au
site primaire puis se diffuse à temps différé aux sites
secondaires.
Un problème de la gestion de copie asymétrique
est donc la panne du site primaire. Dans ce cas, il faut choisir un
remplaçant si l'on veut continuer les mises à jour et celui-ci
peut être fixé par l'administrateur ou élu par un protocole
spécifique de vote majoritaire.
On aboutit alors à une technique asymétrique
mobile dans laquelle le site primaire change dynamiquement selon de
critères qui peuvent être liés à l'application. Le
droit de mise à jour se déplace de site en site par exemple au
fur et à mesure de l'évolution des données.
Réplication symétrique
A l'opposé de la réplication asymétrique
ne privilégie aucune copie. Elle permet les mises à jour
simultanées de toutes les copies par des transactions
différentes.
Réplication symétrique
C'est une technique de gestion de copies ou chaque copie peut
être mise à jour à tous instant et assure la diffusion des
mises à jour aux autres copies.
SITE MAITRE
SITE MAITRE
SITE MAITRE
A noter aussi que le choix d'une technique symétrique
est orthogonal au choix d'un mode de diffusion synchrone ou asynchrone des
mises à jour et on peut donc distinguer la symétrique synchrone
et la symétrique asynchrone.
Figure 3.3. Réplication Symétrique Synchrone
SITE MAITRE
SITE MAITRE
SITE MAITRE
Ici, les mises à jour s'effectuent à partir de
n'importe quel site maitre et se diffusent à temps réel.
Figure 3.4. Réplication Symétrique Synchrone
| 
