07/11/2016
Réplication
Définitions
• Réplique
– Copie d’un ensemble de données de référence.
– Fragment horizontal ou vertical d’une table stockée
dans une base de données qui est copié et transféré
vers une autre base de données
• L’original est appelé la copie primaire (ou maître ou
référence) et les copies sont appelées copies secondaires
(ou esclave ou cible)
• Propagation (diffusion): répercuter la mise à jour
d’une donnée de référence, sur une donnée cible.
1
07/11/2016
Les avantages de la réplication
• Amélioration des performances
– lecture de la copie la plus proche
– éviter le goulot d'étranglement du serveur unique
• Amélioration de la disponibilité
– lors d'une panne d'un serveur, on peut se replier sur
l'autre
– Disponibilité = 1 - probabilité_panneN
• probabilité de panne = 5% et 2 copies => disponibilité = 99.75%
• Meilleure tolérance aux pannes
– possibilité de détecter des pannes diffuses
Accès à des données distantes
• Sans réplication:
– Toutes les applications accèdent au même SGBD
• Surcharge du SGBD
• Dégradation du temps de réponse
• Transferts importants
• Faible tolérance aux pannes
– Simplicité
• Transaction locale
2
07/11/2016
Accès à des données répliquées
• Accès à plusieurs copies dans un environnement
réparti
– Parallélisme
• Equilibrage de charge
• Meilleur temps de réponse
• Réduit les transferts de données
• Disponibilité d’une réplique
– même lorsque la donnée de référence n’est pas
disponible
– Probabilité de panne plus faible
Les problèmes de la réplication
• Convergence
– les copies doivent être maintenues à jour
– à un instant donné, elles peuvent être différentes
– mais elles doivent converger vers un même état
cohérent où toutes les mises à jour sont exécutées
partout dans le même ordre
• Transparence : le SGBD doit assurer
– la diffusion et la réconciliation des mises à jour
– la résistance aux défaillances
3
07/11/2016
Modèle de réplication
• Copies
– Copie Primaire (ou Maître ou Source)
• reçoit les mises à jour
– Copie Secondaire (ou Esclave ou Cible)
• en consultation « seulement »
• peut être désigné Primaire en cas d ’arrêt de la copie
primaire
• Mode de réplication
– Asymétrique
• une copie primaire / N copies secondaires
– Symétrique
• N copies primaires
Mode de réplication:Réplication mono-maître
– Désigner une copie comme primaire (“publisher”) ; les
transactions ne mettent à jour que cette copie,
– les mises à jour de la copie primaire sont envoyées
ultérieurement aux copies secondaires (“subscribers”)
dans l’ordre où elles ont été appliquées ([Link]étrique);
T1: Start
… Write(x1) ... x2
Commit
T2 x1
xm
Tn Copies secondaires
4
07/11/2016
Mode de réplication:Réplication multi-maîtres
• Réplication avec résolution des conflits: Une
règle de priorité permet de résoudre les
conflits ([Link]étrique)
– Systèmes maîtres multiples
– Propagation des mises à jour: plus difficile à sérialiser que
mono-maître
Propagation des Mises à Jour
• de la Source vers la Cible
• Synchrone
– Mises à jour globales dans une même transaction
• + Cohérence forte
• - Ralentit la transaction et le débit
• Asynchrone
– Mises à jour dans des transactions différées
• + Un peu de retard
• - Fusion (manuelle) des copies divergentes
5
07/11/2016
Diffusion (propagation) synchrone
• L’application obtient une réponse après la
propagation
– 1)transaction locale 2) propagation 3) validation
4)réponse
• Propagation : nb de messages échangés entre
sites
– Immédiate après chaque opération (L,E)
• 1 message par opération (L/E): interaction linéaire
– Différée juste avant la fin de la transaction
• 1 message par transaction : interaction constante
• Validation: décision prise
– par plusieurs sites (vote, ex 2PC)
– par chaque site séparément (sans vote)
• Une transaction met à jour
toutes les copies de toutes
les données qu’elle modifie.
+ mise à jour en temps réel des
données
- trop coûteux pour la plupart
des applications
- pas de contrôle de l ’instant
de mise-à-jour
6
07/11/2016
Diffusion (propagation) asynchrone
• L’application obtient une réponse avant la
propagation
– 1) transaction locale 2) validation locale 3)
réponse 4) propagation 5) validation
• Pessimiste :
– Mises à jour et propagations faites dans un ordre
sérialisable prédéfini pour les transactions
• Optimiste :
– Ordre entre transactions calculé en cours
d’exécution en fonction des opérations
commutatives, conflictuelles. Possibilité d’abandon
7
07/11/2016
Diffusion asynchrone - asymétrique
• Collecte des mises-à-jour sur la copie primaire
via :
– des triggers (Oracle, SQL Server, DB2, …)
– Le journal des images après (“log sniffing”) (SQL
Server, DB2, …)
Diffusion asynchrone - asymétrique (2)
– Autre technique : diffuser une requête plutôt que les
données mises à jour (e.g., stored procedure call)
– Problème : assurer le bon ordonnancement des requêtes
• Les requêtes peuvent être diffusées de façon synchrone
à toutes les copies mais la diffusion est validée même si
une mise à jour sur une copie a échoué
• nécessité d’une procédure de reprise dans ce cas
8
07/11/2016
Gestion des défaillances de site
• Défaillance d’une copie secondaire - rien à
faire
– Après reprise, appliquer les mises à jour oubliées
pendant la panne (déterminées à partir du
journal)
– Si panne trop longue, il est préférable d’obtenir
une copie neuve
• Défaillance d’une copie primaire – idem dans
les produits
Défaillance des communications
• Les copies secondaires ne peuvent pas distinguer
1 panne de communication d’une panne de site
• Si les secondaires élisent un nouveau primaire et
l’ancien primaire est toujours vivant, il y aura un
pb de réconciliation ...
• Une solution est qu’une partition du réseau sache
qu’elle est la seule à pouvoir fonctionner, mais
elle ne peut pas communiquer avec les autres
partitions pour le savoir.
– décision statique : la partition qui possède le primaire
gagne
– solution dynamique : consensus majoritaire
9
07/11/2016
La règle d’écriture de Thomas
• Nous considérons trois sites interconnectés par
un réseau informatique (S1, S2, S3).
• Les identifiants de chaque site sont totalement
ordonnés.
• Chaque site réplique une chaîne de caractères s
de valeur initiale "AB".
• Deux utilisateurs génèrent deux opérations
concurrentes op1 et op2. Ils les exécutent
localement et les propagent à leur voisin.
• Nous considérons trois sites
interconnectés par un réseau
informatique (S1, S2, S3).
• Chaque site réplique une
chaîne de caractères s de
valeur initiale "AB".
• Deux utilisateurs génèrent
deux opérations
concurrentes op1 et op2. Ils
les exécutent localement et
les propagent à leur voisin.
10
07/11/2016
• Pour assurer que l’état des copies convergent :
• La règle de Thomas associe à chaque réplique sur un site i une
estampille Ti (h, n) ; h est une heure et n un numéro de site.
• Pour modifier sa réplique, un site génère une opération de mise
à jour contenant la nouvelle valeur et une estampille.
• Cette estampille contient l'heure courante du site et le numéro
de site.
• Cette opération est exécutée immédiatement sur le site puis
propagée aux sites voisins.
• Par exemple, le site 1 peut générer à tout moment l'opération
op1 = set(s," AXB", (13h, 1)), s est une chaine de caractère,
"AXB" la nouvelle valeur, (13h, 1) est l'estampille.
• Tous les produits utilisent une variation de cette règle
Lorsqu'une opération est reçue
sur un site, le site compare
l'estampille de l'opération à celle
de sa réplique.
•si l'estampille de l'opération est
plus récente alors il exécute
l'opération et met à jour
l'estampille,
•sinon, il ignore l'opération.
Une estampille T1(h1, n1) est
plus récente qu'une estampille
T2(h2,n2) si :
(h1> h2)ou((h1= h2)et(n1 > n2))
11
07/11/2016
• La réplication optimiste laisse donc les copies
diverger, à condition qu’elles finissent par
converger.
• Cependant, il faut être capable de faire
converger des copies ayant divergé
• Cependant, dans un contexte collaboratif, le
résultat obtenu n’est pas satisfaisant.
12
