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 limiter l'impact en terme d'indisponibilité de Shinken ).

Préparation

Prévoyez 2 périodes de maintenance car il faudra stoppé le Synchroniser 2 fois.



Il pourrait y avoir des impact sur les Schedulers et Brokers si l'élection dur plus de 9 sec. → l'élection par défaut peux mettre 10 avec la conf par défaut

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

Je vais mettre à jour Haute disponibilité de la base Mongo avec HAProxy (mise en place d'un cluster)


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, voici 2 schémas d'exemple de type de mise en place de clusters ( 3 nœuds ou 2 nœuds et un Arbiter MongoDB ).

Cela permet de rappeler : 

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


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






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

Pour rappel le service mongod permet :  

  • De se charger du stockage des données
  • Il s'assure que les données sont bien répliquées sur les autres nœuds du cluster.


Identifier les mongod à migrer

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())"





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 moteur de stockage est utilisé sur chaque mongod?

Sur chaque serveur ayant un mongod faite la commande suivante :

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 migrer 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())"'





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