Vous êtes sur la page 1sur 14

AU : 2020-2021

Tutoriel sharding et réplication


Objectif :
Nous expliquons, étape par étape, tout au long de ce document les démarches à suivre pour
mettre en place et manipuler un environnement distribué en définissant un sharded cluster
contenant un routeur, un serveur de configuration, des shards et des réplica sets.

Ce tutoriel se compose de deux parties :

 Partie 1 : Création du sharded cluster avec tous ces composants en exécutant le script
demarrage_cluster_mongo.bat. La première section du présent tutoriel explique les
commandes contenues dans le script demarrage_cluster_mongo.bat.
 Partie 2 : Manipulation de ce sharded cluster en appliquant plusieurs scénarios décrits
dans la section 2 de ce tutoriel.

Partie 1 : Création du sharded cluster

Pour créer le sharded cluster, vous devez exécuter (par un double clic) le script
demarrage_cluster_mongo.bat.

Ce script contient cinq étapes. Toutes ces étapes sont succinctement expliquées dans la partie
qui suit la figure ci-dessous.

Figure 1 - Lancement du script

1
AU : 2020-2021

 Etape 1 : Création des répertoires pour les shard servers et les config servers :

md c:\data\sh2 c:\data\sh1
md c:\data\sh1\rep1 c:\data\sh2\rep1
md c:\data\sh1\rep2 c:\data\sh2\rep2
md c:\data\sh1\rep3 c:\data\sh2\rep3
md c:\data\cfg1 c:\data\cfg2 c:\data\cfg3

 Etape 2 : Affectation des ports aux réplica sets et démarrage des mongod :
- RéplicaSet « sh1 » : Démarrage des 3 shards (mongod) en leur attribuant des ports

start /b "sh1-rep1" "mongod" --replSet sh1 --logappend --logpath "C:\data\sh1\rep1\sh1-rep1.log" --


dbpath "C:\data\sh1\rep1" --port 37017 --oplogSize 200 --smallfiles --shardsvr

start /b "sh1-rep2" "mongod" --replSet sh1 --logappend --logpath "C:\data\sh1\rep2\sh1-rep2.log" --


dbpath "C:\data\sh1\rep2" --port 37018 --oplogSize 200 --smallfiles --shardsvr

start /b "sh1-rep3" "mongod" --replSet sh1 --logappend --logpath "C:\data\sh1\rep3\sh1-rep3.log" --


dbpath "C:\data\sh1\rep3" --port 37019 --oplogSize 200 --smallfiles –shardsvr

- RéplicaSet « sh2 » : Démarrage des 3 shards (mongod) en leur attribuant des ports

start /b "sh2-rep1" "mongod" --replSet sh2 --logappend --logpath "C:\data\sh2\rep1\sh2-rep1.log" --


dbpath "C:\data\sh2\rep1" --port 47017 --oplogSize 200 --smallfiles --shardsvr

start /b "sh2-rep2" "mongod" --replSet sh2 --logappend --logpath "C:\data\sh2\rep2\sh2-rep2.log" --


dbpath "C:\data\sh2\rep2" --port 47018 --oplogSize 200 --smallfiles --shardsvr

start /b "sh2-rep3" "mongod" --replSet sh2 --logappend --logpath "C:\data\sh2\rep3\sh2-rep3.log" --


dbpath "C:\data\sh2\rep3" --port 47019 --oplogSize 200 --smallfiles –shardsvr

- RéplicaSet « cfgRep » : Démarrage des serveurs de configuration (mongod) en leur


attribuant des ports.
A noter que les serveurs de configuration stockent les métadonnées d'un sharded cluster.
Les métadonnées reflètent l'état et l'organisation de toutes les données et composants du
sharded cluster.

start /b "cfg1" "mongod" --logappend --logpath "C:\data\cfg1\cfg1.log" --dbpath "C:\data\cfg1" --port


37020 --configsvr --replSet cfgRep

start /b "cfg2" "mongod" --logappend --logpath "C:\data\cfg2\cfg2.log" --dbpath "C:\data\cfg2" --port


37021 --configsvr --replSet cfgRep

2
AU : 2020-2021

start /b "cfg3" "mongod" --logappend --logpath "C:\data\cfg3\cfg3.log" --dbpath "C:\data\cfg3" --port


37022 --configsvr --replSet cfgRep

 Etape 3 : Configuration des réplicaSet sh1, sh2 et cfgRep

Cette étape va permettre de configurer les réplicaSet : identifier et lier les instances mongod
(shard ou serveur de configuration) appartenant à un même réplicaSet.

start /b "configure sh1" "mongo" --port 37017 --eval "config1 =


{_id:'sh1',members:[{_id:0,host:'localhost:37017'},{_id:1,host:'localhost:37018'},{_id:2,host:'
localhost:37019'}]};rs.initiate(config1);"

timeout /t 5

start /b "configure sh2" "mongo" --port 47017 --eval "config2 =


{_id:'sh2',members:[{_id:0,host:'localhost:47017'},{_id:1,host:'localhost:47018'},{_id:2,host:'
localhost:47019'}]};rs.initiate(config2);"

timeout /t 5

start /b "configure cfg" "mongo" --port 37020 --eval "config3 =


{_id:'cfgRep',members:[{_id:0,host:'localhost:37020'},{_id:1,host:'localhost:37021'},{_id:2,h
ost:'localhost:37022'}]};rs.initiate(config3);"

 Etape 4 : Démarrage du routeur mongos

L’instance mongos est chargée de l’acheminent des requêtes et l’écriture des opérations sur les
shards d'un sharded cluster. Mongos fournit la seule interface à un sharded cluster du point de
vue des applications clientes. Les applications ne se connectent ou ne communiquent jamais
directement avec les shards.

Le code ci-dessous permet de lancer le routeur mongos en lui donnant comme paramètre le
réplicaSet des serveurs de configuration « cfgRep ».

start /b "mongos_" "mongos" --port 37023 --logappend --logpath "C:\data\mongos.log" --


configdb cfgRep/localhost:37020,localhost:37021,localhost:37022

 Etape 5 : Configuration du sharding

Cette étape permet d’indiquer à mongos de considérer les réplicaSets des shards « sh1 » et
« sh2 ».

3
AU : 2020-2021

start /b "configure shard" "mongo" --port 37023 –eval "db.adminCommand({addshard:'sh1/localhost:37017'});"

start /b "configure shard" "mongo" --port 37023 --eval "db.adminCommand({addshard:'sh2/localhost:47017'});"

Partie 2 : Manipulation du sharded cluster

Cette partie va vous permettre d’exécuter des scénarios pour la manipulation du sharded cluster.

 Scénario 1 : Test sharding

Ce scénario va permettre d’activer le sharding sur la base de données « test » et plus précisément
sur la collection « users » (non encore créée):

1- Lancement d’une nouvelle invite de commande cmd


2- Exécution des commandes :

mongo –host localhost –port 37023 Vous serez alors connecté sur le mongos
mongos> use test
mongos> sh.enableSharding("test")

3- Indication de la clé de sharding de la collection « users ».

db.users.ensureIndex( { _id : "hashed" } )


sh.shardCollection("test.users", { "_id": "hashed" } )

4
AU : 2020-2021

4- Création et alimentation de la collection « users » de la base de données « test » en insérant


50000 documents json (cette insertion peut prendre quelques minutes).

for (var i = 1;i <=50000;i++) db.users.insert({_id:i,name:"test",country:"Tunisia"})

5- Affichage de l’état (status) du sharding :

sh.status()

5
AU : 2020-2021

Les documents de la collection « users » ont été répartis sur les deux shards « sh1 » et « sh2 »
avec deux chunks (segments) sur chaque shard.

Notez les détails de répartition des documents selon les valeurs de la clé de partitionnement _id,
par exemple, les documents dont la valeur de l’_id est comprise entre 0 et
4611686018427387902 sont mis sur le shard « sh2 ».

 Scénario 2 : Test de suppression de shards


1- Suppression du shard « sh2 » (ainsi que ses réplicas)

db.adminCommand( { removeShard: "sh2" } )

6
AU : 2020-2021

2- Affichage de la liste des shards du cluster


use admin
db.runCommand({listshards:1})

Constatez que l’état de « sh2 » est draining (purgé).


3- Affichage de toutes les informations sur le sharding
printShardingStatus()

7
AU : 2020-2021

Remarquez ici que les 2 chunks de la collection « users » qui étaient sur le shard « sh2 » ont
été déplacés vers le shard « sh1 »  aucune donnée n’a donc été perdue.

 Scénario 3 : Réplicaion

1- Ouvrir une nouvelle invite de commande cmd


2- Se connecter au premier réplica « rep1 » du shard « sh1 » sur le port 37017 en exécutant la
commande :
mongo --port 37017

La désignation du serveur primaire se fait d’une façon aléatoire.

Si le port 37017 correspond à un serveur secondaire, connectez-vous au serveur primaire


(reconnectez-vous au niveau du port 37018 ou 37019).
8
AU : 2020-2021

3- Changement de la priorité d’un serveur secondaire :

Le but de cette manipulation est de changer la priorité d’un serveur secondaire. Notez que le
membre 0 correspond au port 37017, 1 au port 37018 et 2 au port 37019.

Dans cet exemple, étant donné que le 37017 correspond au serveur primaire, le membre 1
correspond à un serveur secondaire. Nous allons donc lui attribuer une priorité supérieure à
celle du master. (Changer la priorité d’un membre secondaire selon le résultat trouvé).

cfg = rs.conf()
cfg.members[1].priority = 2
rs.config(cfg) //pour appliquer les changements

Il est normal de voir que le serveur courant est encore primaire, attendez une dizaine de seconde
et faites un ou deux retours à la ligne, vous verrez qu’il est devenu secondaire.

4- Connexion au rep2 du shard1 sur le port 37018 (recommencer les étapes 1 et 2 en changeant
le port)

9
AU : 2020-2021

Constatez que le membre 1 (ici port 37018), est donc élu automatiquement en tant que primaire.

5- Synchronisation entre les nœuds :

Connectez-vous au master, ici c’est le 37018 et exécuter la commande suivante pour forcer la
synchronisation entre les serveurs secondaires et le serveur primaire.

rs.printSlaveReplicationInfo() // à partir du master

 Scénario 4 : Test de synchronisation


1- Création et alimentation de la nouvelle base de données « mabd » au niveau du nœud
primaire.

10
AU : 2020-2021

use mabd
db.tab.insert({name:"alain",age:26,hobby:"database"})
db.tab.count()

Maintenant, on se connecte à un réplica secondaire et on teste la synchronisation (on vérifie si


la base « mabd » a été dupliquée sur le réplica secondaire ou non).

mongo --port 37017


db.getMongo().setSlaveOk() // synchronisation avec le primary
show dbs
db.tab.find()

11
AU : 2020-2021

On voit dans la figure ci-dessus que la base de données « mabd » existe bien sur le nœud
secondaire. De plus, si on lance la requête db.tab.find(), on voit le retour d’un des documents
insérés dans la base de données « mabd » au niveau du nœud primaire.

 Scénario 5 : Test de tolérance aux pannes


1- Connexion au réplica primary sur le port 37018 dans une nouvelle invite de commande cmd

mongo --port 37018

2- Arrêt du serveur primary

use admin
db.shutdownServer()

12
AU : 2020-2021

Un des réplicas secondaires va être élu automatiquement comme primaire (vu que le réplica
primaire a été arrêté).

Vérifiez lequel des nœuds secondaires est devenu primaire, dans cet exemple, c’est le 37017
qui est devenu primaire.

mongo --port 37017

3- Vérification de l’état du réplicaSet « sh1 » :

rs.status()

13
AU : 2020-2021

Constatez par exemple, que le membre 0, au port 37017 est le primaire et que le membre 1 n’est
pas atteignable mais qu’il est en bonne santé.

Remarque importante:

Si vous voulez refaire ce tutoriel, il est conseillé de supprimer les dossiers des réplicas créés au
niveau de votre système et contenus dans le répertoire C:\data\db.

14