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. Vérifier aussi les priorités afin de vérifier si vous avez un PRIMARY par défaut, comme c'est le cas dans l'exemple à droite. |
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 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 :
Description des états du Cluster MongoDB : https://docs.mongodb.com/v3.0/reference/replica-states/ |
Procédure de migration d'un mongod
Migration des mongod SECONDARY
É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 * |
Modifier le type de moteur vers WiredTiger
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 |