Page History

Concept

Cette procédure permet la migration de MMapV1 vers WiredTiger sans interruption de service de Shinken (  le seul impact observable pourra éventuellement être un peu de lenteur sur les accès à MongoDB ) en se basant sur la haute disponibilité du Cluster MongoDB.

Préparation

Rappel des concepts d'architecture de Cluster MongoDB

Pour une meilleure compréhension de la procédure, voici deux schémas représentant des architectures de clusters MongoDB ( Primaire - Secondaire - Secondaire ou Primaire - Secondaire - Arbiter ).

Cela permet de rappeler : 

• les différents démons utilisés par le cluster MongoDB.
• ainsi que les ports par défaut utilisés.

Dans les schémas, le port du serveur mongod est 27018, mais comme ce port peut être modifié dans la configuration du démon, pour le reste de la procédure, le terme de PORT_DE_MONGOD sera utilisé.

Pour rappel, le serveur mongod permet :  

• de stocker des données.
• de s'assurer que les données sont bien répliquées sur les autres nœuds du cluster.

Identifier les mongod à migrer

Avant de démarrer la procédure, faire un inventaire des serveurs à migrer avec la commande suivante :

mongo shinken --port  PORT_DE_MONGOD --quiet --eval "printjson(rs.conf())"

Moteur de stockage utilisé sur chaque mongod

Sur chaque serveur ayant un mongod exécuter la commande suivante :

mongo shinken --port PORT_DE_MONGOD --quiet --eval "print(db.serverStatus().storageEngine.name)"

Terminal pour surveiller l'état du cluster

Dans un terminal, qui servira à surveiller l'état du cluster, lancer la commande suivante :

watch -n 1 'mongo shinken --port PORT_DE_MONGOD --quiet --eval "printjson(rs.status())"'

Procédure de migration

Migration des mongod SECONDARY

Les mongod secondaires doivent être migrés l'un après l'autre.

Éteindre mongod

service mongod stop

Supprimer les données dans la base

Debian 13

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Modifier le type de moteur vers WiredTiger

Mettre dans le fichier  /etc/mongod.conf :

storage:
     engine: wiredTiger

Démarrer mongod

Attendre la fin de la synchronisation avec le PRIMARY 

Anchor
synchronisation synchronisation

Le mongod n'a plus de données.

Le système de synchronisation du cluster va remettre les données en place dans le nœud, comme lorsqu'on ajoute un nouveau membre au cluster MongoDB.
Il est impératif d'attendre la resynchronisation des données avant de continuer la suite de la migration.

La commande suivante donne l'état de la réplication sur le mongod en cours de migration :

watch -n 1 'mongo shinken --port PORT_DE_MONGOD --quiet --eval "printjson(db.printSlaveReplicationInfo())"'

Une fois que le mongod est synchronisé ( "0 secs (0 hrs) behind the primary" ), il est possible de passer à un autre nœud ( SECONDARY ou PRIMARY )

Exemple de résultat de la commande de surveillance, une fois la synchronisation finie.

Migration du mongod PRIMARY

La migration du mongod PRIMARY va provoquer l'élection d'un nouveau PRIMARY.

Durant le temps de l'élection, il ne sera pas possible d'écrire dans la base, les manipulations suivantes vont limiter le temps d'indisponibilité de la base à 3 secondes.

Les démons de Shinken se reconnecteront au changement de PRIMARY. 

Passer le PRIMARY en SECONDARY

Sur le nœud primaire, exécuter la commande suivante :

mongo shinken --port PORT_DE_MONGOD --quiet --eval "rs.stepDown()"

watch -n 1 'mongo shinken --port PORT_DE_MONGOD --quiet --eval "printjson(rs.status())"'

Éteindre mongod

Supprimer les données dans la base

Debian 13

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Modifier le type de moteur vers WiredTiger

Mettre dans le fichier /etc/mongod.conf :

storage:
     engine: wiredTiger

Démarrer mongod

Attendre la fin de la synchronisation

Attendre la fin de la synchronisation comme indiqué dans la section Attendre la fin de la synchronisation avec le PRIMARY ci-dessus.