Objectif

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

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

Préparation

Prévoyez 2 périodes de maintenance car il faudra stoppé le Synchroniser 2 fois pendant l'quelque secondes 9 sec + le temps de démarrage du Synchroniser.

Il pourrait y avoir des impact sur les Schedulers et Brokers si l'élection dur plus de 9 sec.


Alors il faudra augmenté auto_reconnect_max_try/auto_reconnect_sleep_between_try dans les modules SLA / Event 


Avant toute opération, faites un shinken-backup complet ( ou avec les options qui permettent de sauvegarder les données ) du serveur de production impacté.


Rappel des concepts d'architecture de Cluster MongoDB

Pour une meilleur compréhension de la procédure, voir 2 schémas d'exemple de type de mise en place de clusters ( 3 nœuds, ou 2 nœuds et un Arbiter ).

Cela permet de rappeler

  • les différents démons utilisé par mongo
  • ainsi que les ports par défaut connues

Attention, il se peut que votre installation ait des différences.



Shema avec 2 mongo et un Abiter

Dans les schémas, le port de Mongod est 27018 ( par défaut dans MongoDB ), mais comme ce port peut être modifié, pour le reste de la procédure, nous utiliserons le terme de PORT_DE_MONGOD.

Identifier les mongod à migrer


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


Exemple de sortie avec cadre rouge


Vérifier que les champs "host" contiennent bien les adresses des serveurs que vous voulez migrer

Vérifier si vous avez un Arbiter MongoDB que celui ci est bien "arbiterOnly" : true


Quel format de donnée votre de donnée suutilise sur chaque mongod?

Suivant serveur ayant un mongod :

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


Si le format est WiredTiger, il ne serra pas nécessaire de migré ce mongod


Préparer vous un fenêtre pour l'état du cluster


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


Exemple de sortie avec une explication

Utiliser un PORT_DE_MONGOD d'un mongod sur lequel vous ne faite pas de migration 

Le mieux est d'utiliser cette commande dans un shell à par toujours visible afin de :

  • Vérifier quand la migration est fini "stateStr"  "STARTUP2" → "SECONDARY"/"PRIMARY"
  • Vérifier lors que l'on va coupé le "PRIMARY" qu'un autre membre "SECONDARY" va bien être élu  "PRIMARY"

Description des états du Cluster MongoDB : https://docs.mongodb.com/v3.0/reference/replica-states/


Procédure de migration d'un mongod

Éteindre mongod

Si ce Cluster MongoDB contient des données de Synchronizer et qu'il y a un membre avec une "priority" plus grande que les autres membre

Pour le membre "PRIMARY" avec la plus grande "priority" ( Voir "Surveiller l'état du cluster" pour vérifié qui est le "PRIMARY" ) il faudra éteindre le Synchronizer avant et le rallumer après l'élection d'un nouveau  "PRIMARY"


service mongod stop


Supprimer les données dans la base

cd /var/lib/mongo
rm -fr *


Démarré mongod

Si ce Cluster MongoDB contient des données de Synchronizer et qu'il y a un membre avec une "priority" plus grande que les autres membre

Si vous avez migré le membre "PRIMARY" avec la plus grande "priority" ( Voir "Surveiller l'état du cluster" pour vérifié qui est le "PRIMARY" ) il faudra éteindre le Synchronizer avant et le rallumer après l'élection d'un nouveau  "PRIMARY"

service mongod start