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 Client 1 Haute disponibilité
diminuer le trafic réseau et localité des clients
Copie 3 Site central Copie 3
synchronisation
Sites
Copie 1 Copie 2 départementaux Copie 1 Copie 2
accès accès Client 2 Client 3 Client 4 Client 5
Client 1 Client 2 Client 3 Client 4 Client 5
 " # $
Client mobile Site central

Check in (1) Unité de réplication : relation complète ou

Copie 1 Copie 2 résultat d'
une requête SQL de type SELECT
Check out (3)
Maj locales (2) Gestion conflits (4) données fréquemment accédées en lecture
et avec des clients répartis sur de nombreux
Check in : recopie du site central vers le client mobile
client dispose d ’une copie locale (peut travailler en mode sites
déconnecté) données peu fréquemment mises à jour
check out : client renvoie sa copie locale modifiée vers le
site central (sinon le coût est trop élevé)
site central est modifié mais si plusieurs clients mobiles
il peut y avoir risque de conflits
(nécessité de gérer le conflit)
!

& & ( ) *
À priori une mise à jour doit être propagée
lecture écriture lecture écriture "immédiatement" sur l' ensemble des copies
mais cela coûte cher donc on peut utiliser
Copie 1 Copie 3
des modes de réplication plus faibles :
asymétrie entre les copies (une copie primaire et
lecture écriture lecture écriture
des copies secondaires)
propagation non immédiate
Copie 2 Copie 4
propagation sur un sous-ensemble des copies

Comment et quand propager une écriture faite le choix dépend de l' application mais on ne
sur une copie sur l'
ensemble des copies ? peut avoir tout à la fois!

% '
, - # & /0
Copie primaire Copies secondaires Périodique : défini par un intervalle de temps ou une
lecture "quantité" de mises à jour
peut se faire par recopie de la copie primaire ou

rafraichissement
lecture écriture Copie 2 bien en maintenant et envoyant des deltas par
rapport à la dernière version
lecture
Copie 1 optimise le trafic réseau
augmente le temps de construction de la nouvelle copie
Copie 3 nécessite un travail spécifique sur le SGBD qui n'
est pas
lecture toujours possible selon la requête SELECT définissant la
copie (juste pour les SELECT mono-relation sans agrégat)

Copie 4

+ .

12 ( 34 2 , - #
Permet de faire de la réplication avec des coûts de
mise à jour réduits lecture écriture
pas de conflit en mise à jour
lecture écriture Copie 2
toutes les copies ne sont pas symétriques

propagation
suppose des taux de mise à jour assez faibles lecture écriture
Copie 1
pas possible pour toutes les applications (gestion
boursière par exemple) Copie 3
est quand même le mode le plus utilisé lecture écriture
variante : la notion de copie primaire est vue comme un
privilège qui circule entre les copies (symétrise Copie 4
l'
architecture)
& ( *
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