Bases de données distribuées
Systèmes NoSQL : la réplication
Répliquer, à quoi ça sert?
Outil indispensable, universel pour la robustesse des systèmes distribués.
Tolérance aux pannes
Vous cherchez un document sur S1, qui est en panne ? On le trouvera sur S2
Distribution des lectures
Répartissons les lectures sur S1,S2, . . . ,Sn pour satisfaire les millions de requêtes de
nos clients.
Distribution des écritures ?
Oui, mais attention, il faut réconcilier les données ensuite.
et autres avantages, comme la construction d’un index sur un des serveurs sans
affecter les autres,
Le bon niveau de réplication ? Trois copies pour une sécurité totale ; deux au
minimum.
2
Maître-Esclave
Deux organisations principales. La première (plus
courante) est dite maître-esclave.
3
Maître-Esclave
Le maître est notamment charge des tâches
administratives du système
ajouter un nœud, en supprimer un autre,
surveiller la cohérence et la disponibilité du système,
appliquer une méthode de reprise sur panne le cas échéant.
Souvent charge aussi de communiquer avec l’application
cliente (qui constitue un troisième type de nœud)
4
Master-Master
C’est la démocratie ! Il n’y a que des maîtres (master-
master, ou aussi multi-nœuds).
Plus robuste en théorie, mais soulève des problèmes
compliqués (donc, moins courant).
5
Failover (reprise sur panne)
Un système distribué peut s’appuyer des centaines, des
milliers de serveurs : il y a des pannes tout le temps.
Caractéristique d’un bon système : tolérants aux pannes,
assure une disponibilité 24/7.
surveillance automatisée de tous les nœuds participants
(heartbeat, messages toutes les n secondes).
méthode de reprise sur panne (failover) basée sur la
redondance/réplication.
Un cas particulièrement épineux : le partitionnement
réseau.
6
La réplication, comment ?
Deux techniques utilisées pour limiter le temps d’attente, toutes deux affectant (un peu)
la sécurité des opérations:
écriture en mémoire RAM, et fichier journal (log);
réplication asynchrone/ synchrone
En cas de panne avant l’opération de flush()?
- les données modifiées n’ont pas été écrites dans la base,
- mais le journal (log) est préservé.
→ La reprise sur panne consiste à ré-effectuer les opérations enregistrées dans
le log.
7
La réplication, comment?
Méthode générale de réplication
Une application (le client) demande au système (le serveur) S1 l’écriture d’un
document (unité d’information).
le serveur écrit le document sur le disque ;
S1 transmet la demande d’écriture à un ou plusieurs autres serveurs S2, . . .
,Sn, créant des replicas ou copies ;
S1 “rend la main” au client.
Essentiel, réplication synchrone/asynchrone ?
synchrone : S1 attend confirmation de S2, . . . ,Sn avant de rendre la main ;
asynchrone : S1 rend la main sans attendre.
Conséquences
Une réplication asynchrone est beaucoup plus rapide, mais elle favorise les
incohérences, au moins temporaires.
8
Réplication avec écritures synchrones
Le client est acquitté quand tous les serveurs ont effectué l’écriture.
Sécurité totale ; cohérence forte ; très lent.
9
Réplication avec écritures asynchrones
Le client est acquitté quand un des serveurs a effectué l’écriture. Les autres
écritures se font indépendamment.
Sécurité partielle ; cohérence faible ; Efficace.
10
Architectures avec réplication : topologie et
(a)synchronicité
Trois combinaisons sont possibles en pratique
11
Cas A
Topologie de type maître-esclave
Ecritures synchrones
Toutes les écritures se font par une requête adressée au nœud-
maître qui se charge de les distribuer aux nœuds-esclaves.
L’acquittement n’est envoyé au client que quand toutes les copies
sont en phase.
➪ Assure la cohérence forte, car toute lecture du document,
quel que soit le nœud sur lequel elle est effectuée, renvoie la
même version, celle qui vient d’être mise à jour.
➪ Cette cohérence se fait au prix
de l’attente que la
synchronisation soit complète,
et ce à chaque écriture.
12
Cas B
Topologie de type maître-esclave
Ecritures sont asynchrones.
➪ La cohérence n’est plus forte: il est possible d’écrire en s’adressant au
nœud-maître, et de lire sur un nœud-esclave. Si la lecture
s’effectue avant la synchronisation, il est possible que la version du
document retournée soit non pas d mais d−1, celle qui précède la mise à
jour.
C’est le mode d’opération le plus courant des systèmes NoSQL, qui autorisent
donc un décalage potentiel entre l’écriture et la lecture.
La garantie = décalage temporaire, toutes les versions vont être
synchronisées “à terme” (délai non précisé). On parle donc de cohérence
à terme (eventual consistency en anglais).
13
Cas C
Topologie multi-nœuds
Mode asynchrone
Les écritures peuvent se faire sur n’importe quel nœud, ce qui
améliore la scalabilité du système.
Inconvénient : deux écritures concurrentes du même document
peuvent s’effectuer en parallèle sur deux nœuds distincts.
Au moment où la synchronisation s’effectue, le système va
découvrir (au mieux) que les deux versions sont en conflit.
Le conflit est reporté à
l’application qui doit effectuer
une réconciliation (il n’existe pas
de mode automatique de
réconciliation).
14
Réplication et reprise sur panne (failover)
Principe général : tout le monde est interconnecté et échange des messages
(heartbeat).
Si un esclave tombe en panne, le système continue à fonctionner, tant
qu’il est en contact avec une majorité d’esclaves
Les lectures sont dirigées vers les autres nœuds et une nouvelle réplication
vers un autre serveur esclave est initiée.
Si le maître tombe en panne, les slaves doivent élire un nouveau maître
15
Réplication dans MongoDB
MongoDB : Système reparti (distribué) maître-esclaves, utilisant une réplication
asynchrone
L’ensemble de serveurs mongoDB (grappe de serveurs) partageant des replicas d’un
même ensemble de documents, est appelé Replica Set
Typiquement un RS contient un maître, i.e. Primary et deux esclaves, i.e.
Secondaries et éventuellement un serveur arbitre.
Dans une grappe MongoDB avec des documents repartis, on peut trouver plusieurs
replica sets, chacun contenant un sous-ensemble d’une très grande collection.
16
Replica Set, Primary, Secondaries
Primary (maître)
Les écritures ont toujours lieu sur le Primary (il en existe un seul dans un replica set)
Consigne toutes les opérations de modification des données dans un fichier journal (log),
appelé opLog (operations log)
Secondary (esclave)
Récupère l’opLog (du primary ou de n’importe quel autre secondary) et le stocke localement
dans la collection [Link]
Met a jour la copie locale à partir de l’opLog récupéré
La mise-à-jour des copies est asynchrone, i.e. on n’attend pas la confirmation de l’ écriture
des copies.
17
Election d’un maître dans MongoDB
Serveur arbitre (arbiter)
Pour garantir qu’une élection aboutisse, il faut que le nombre
de participants soit impair
On peut ajouter un serveur arbitre pour rendre impair le
nombre de participants
Arbitre : serveur ne contenant pas de replica, mais participant
au vote.
Pour aller plus loin : Replication Election and Consensus Algorithm Refinements for MongoDB
[Link]
18