Gestion des copies multiples réplication

Augmenter la disponibilité des données
augmenter la localité des données et donc
les performances
réduire la charge réseau (éviter de faire tout
converger vers un serveur unique)
supporter la déconnexion des clients
mais
prend plus de place
nécessite des protocoles sophistiqués pour
supporter les mises à jour
Grand nombre de clients
hiérarchisation des copies
diminuer le trafic réseau
Copie 3
Site central
synchronisation
Copie 1
Copie 2
accès
Client 1
Client 2
Client 3
Haute disponibilité
et localité des clients
Client 1
Copie 3
Sites
départementaux
accès
Client 4
Client 5
Copie 1
Client 2
Client 3
Copie 2
Client 4
Client 5
"
Client mobile
Copie 1
#
$
Site central
Check in (1)
Unité de réplication : relation complète ou
résultat d'
une requête SQL de type SELECT
données fréquemment accédées en lecture
et avec des clients répartis sur de nombreux
sites
données peu fréquemment mises à jour
(sinon le coût est trop élevé)
Copie 2
Check out (3)
Gestion conflits (4)
Maj locales (2)
Check in : recopie du site central vers le client mobile
client dispose d ’une copie locale (peut travailler en mode
déconnecté)
check out : client renvoie sa copie locale modifiée vers le
site central
site central est modifié mais si plusieurs clients mobiles
il peut y avoir risque de conflits
(nécessité de gérer le conflit)
!
&
&
lecture
écriture lecture
Copie 1
lecture
Copie 2
)
*
À priori une mise à jour doit être propagée
"immédiatement" sur l'
ensemble des copies
mais cela coûte cher donc on peut utiliser
des modes de réplication plus faibles :
écriture
Copie 3
écriture lecture
(
asymétrie entre les copies (une copie primaire et
des copies secondaires)
propagation non immédiate
propagation sur un sous-ensemble des copies
écriture
Copie 4
le choix dépend de l'
application mais on ne
peut avoir tout à la fois!
Comment et quand propager une écriture faite
sur une copie sur l'
ensemble des copies ?
%
'
,
-
&
#
Copie primaire
Périodique : défini par un intervalle de temps ou une
"quantité" de mises à jour
peut se faire par recopie de la copie primaire ou
bien en maintenant et envoyant des deltas par
rapport à la dernière version
Copies secondaires
écriture
Copie 1
rafraichissement
lecture
lecture
/0
Copie 2
lecture
optimise le trafic réseau
augmente le temps de construction de la nouvelle copie
nécessite un travail spécifique sur le SGBD qui n'
est pas
toujours possible selon la requête SELECT définissant la
copie (juste pour les SELECT mono-relation sans agrégat)
Copie 3
lecture
Copie 4
+
( 34
2
Permet de faire de la réplication avec des coûts de
mise à jour réduits
pas de conflit en mise à jour
toutes les copies ne sont pas symétriques
suppose des taux de mise à jour assez faibles
pas possible pour toutes les applications (gestion
boursière par exemple)
est quand même le mode le plus utilisé
variante : la notion de copie primaire est vue comme un
privilège qui circule entre les copies (symétrise
l'
architecture)
,
-
#
lecture
lecture
écriture
Copie 1
propagation
12
.
écriture
Copie 2
lecture
écriture
Copie 3
lecture
écriture
Copie 4
&
(
*
Propagation synchrone : 2 transactions accédant en
même temps à 2 copies voient la même information
opération de mise à jour + propagation = même transaction
(transaction répartie avec V2P)
a les défauts de la V2P (notamment passage à l'
échelle)
peut s'
automatiser via des triggers
propagation asynchrone
opération de mise à jour et propagation dans des
transactions différentes : garantie d'
exécution de la
transaction de propagation (utilisation d'
un MOM)
risque de conflits (2 transactions mettant à jour "en même
temps" deux copies de la même information)
passe mieux à l'
échelle