| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
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
| Warning | ||
|---|---|---|
| ||
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
| Panel |
|---|
|
Liste des commandes pour suivre l'état de votre Cluster MongoDB
Quel format de donnée votre MongoDB utilise?
| Code Block | ||
|---|---|---|
| ||
mongo shinken --port PORT_DE_MONGOD --quiet --eval "print(db.serverStatus().storageEngine.name)" |
| Tip |
|---|
| Si le format est WiredTiger, il ne serra pas nécessaire de migré ce mongod |
Récupérer la configuration du cluster
| Code Block | ||
|---|---|---|
| ||
mongo shinken --port PORT_DE_MONGOD --quiet --eval "printjson(rs.conf())" |
| Tip |
|---|
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
| Code Block | ||
|---|---|---|
| ||
watch -n 1 'mongo shinken --port PORT_DE_MONGOD --quiet --eval "printjson(rs.status())"' |
| Tip |
|---|
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/ |
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