Page History

Concept

Le but est de se baser sur la haute disponibilité du Cluster MongoDB pour faire la Cette procédure permet la migration de MMapV1 vers WiredTiger .

De cette manière, les interruptions de Shinken vont se limiter à quelque redémarrage de Synchronizer ( et donc limiter l'impact en terme d'indisponibilité de Shinken ).

Préparation

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 meilleur meilleure compréhension de la procédure, voici 2 schémas d'exemple de type de mise en place deux schémas représentant des architectures de clusters ( 3 nœuds ou 2 nœuds et un Arbiter MongoDB MongoDB ( Primaire - Secondaire - Secondaire ou Primaire - Secondaire - Arbiter ).

Cela permet de rappeler : 

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

Dans les schémas, le port du service serveur mongod est 27018 ( par défaut dans l'exemple ), mais comme ce port peut être modifié dans la configuration du démon, pour le reste de la procédure, nous utiliserons le terme de PORT_DE_MONGOD sera utilisé.

Pour rappel, le service serveur mongod permet :  

• De se charger du stockage de stocker des données.
• Il de s'assure 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 :

Depuis le document qui décrit votre infrastructure lister les serveurs que vous voulez migrer.

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

Moteur de stockage

utilisé sur chaque mongod

Sur chaque serveur ayant un mongod faite 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.

donné à la suite de la migration. Le système de synchronisation du cluster va remettre les donnés données en place dans le membrenœud, comme lors que llorsqu'on ajoute un nouveau membre au cluster MongoDB.
Il faut donc est impératif d'attendre la re synchronisation resynchronisation des donnée données avant de continuer la suite de la migration.

La commande suivant vous suivante donne l'état de la réplication sur le mongod que nous avons migré toute les secondes.en cours de migration :

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

Une fois que le mongod est synchroniser synchronisé ( "0 secs (0 hrs) behind the primary" ) alors vous pouvez passer aux autres , il est possible de passer à un autre nœud ( SECONDARY ou au 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 un nouvelle l'élection d'un nouveau PRIMARY.

Durant le temps de l'élection, il ne sera pas possible d'écrire dans la base. Les manipulations suivant vont limité , les manipulations suivantes vont limiter le temps d'indisponibilité de la base à 3 secondes, mais il faudra redémarré le Synchronizer pour prendre en compte le changement de PRIMARY. Les autres démons se reconnecterons .

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

Eteindre le Synchronizer ( Si besoin )

Paramètres globaux ( synchronizer.cfg )pageDefaultLink[destination=Optional[PageResourceIdentifier[spaceKey=<null>,title=Paramètres globaux ( synchronizer.cfg )]],body=Optional.empty,tooltip=Optional.empty,anchor=Optional.empty,target=Optional.empty]nopaneltrue

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

service mongod stop

Rallumer le Synchronizer après élection du nouveau PRIMARY( Si besoin )

Supprimer les données dans la base

Debian 13

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

rm -fr

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

Supprimer les données dans la base

cd /var/lib/mongo
rm -fr /*

Modifier le type de moteur vers WiredTiger

Mettre dans le fichier fichier /etc/mongod.conf :

storage:
     engine: wiredTiger

Eteindre le Synchronizer ( Si besoin )

Démarrer mongod

Démarré mongod

service mongod start

Rallumer le Synchronizer après élection du nouveau PRIMARY( Si besoin )

Pensé à suivre les élections avec votre fenêtre qui à la commande 

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.