Objectif

Le but de cette page est de migré les moteurs de stockage des serveurs qui contient les données (mongod) de MMapV1 vers WiredTiger

Prévoyez 2 période de maintenance car il faudra stoppé le Synchroniser 2 fois pendant 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 

Préparation


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é.


Exemple d'architecture de Cluster MongoDB



Liste des commandes pour suivre l'état de votre Cluster MongoDB

Quel format de donnée votre MongoDB utilise?


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


Récupérer la configuration du cluster


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


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


Surveiller l'état du cluster


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


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/


Prévoyez une période de maintenance car il faudra stoppé le Synchroniser et il pourrait y avoir des impact sur les Schedulers et Brokers


→ Pas de doc pour  auto_reconnect_max_try et auto_reconnect_sleep_between_try 

Note : si l'élection dur plus de 9 sec il faudra augmenté auto_reconnect_max_try/auto_reconnect_sleep_between_try dans les modules SLA / Event



on coupe le mongod
on del les donnée
on reboot le mongo