L'idée est de faire la migration sur une autre machine : la machine de travaille pour limité l'interruption de service sur la prod
La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo). Il est possible de surveiller cet écart de consommation, et même la réduire.
Avant toute opération, faite un shinken-backup complet du serveur impacté ou avec les options qui permet de sauvegarder données |
Il est fortement recommandé de migrer sur le moteur Wired Tiger, qui permet d'avoir de meilleures performances et un espace disque consommé plus faible (moins de fragmentation et compression de données).
Vérifier que le type de moteur de stockage est bien mmapv1:
mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" --> mmapv1 |
Ensuite on récupère des stats de la base qui vont nous servir a vérifié que l'on a les données
mongo shinken --quiet --eval 'db.getCollectionNames()' | tee db_info.info
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));' | tee db_info.info
mongo shinken --quiet --eval 'db.getCollection("sla_archive").count();' | tee db_info.info |
Vérifier que le type de moteur de stockage est bien mmapv1:
mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" --> mmapv1 |
Pour changer le moteur si ce n'est pas le bon, mettre dans le fichier /etc/mongod.conf
storage:
engine: mmapv1 |
et supprimer les données dans la base puis reboot mongod:
service mongod stop cd /var/lib/mongo rm -fr * service mongod start mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" --> mmapv1 |
Eteindre la base et la vide pour préparé la base a récupère les données de la production
service mongod stop cd /var/lib/mongo rm -fr * |
Eteindre Shinken, Eteindre mongo, copier les données sur la machine de travaille.
Dans cet exemple on va le faire avec une archive pour que le SCP soit plus rapide si vous avez un très bon débit et des CPU faible sur votre machine de prod fait un scp de /var/lib/mongo direct
service shinken stop cd /var/lib/ tar cvzf mongo.tar.gz mongo/ scp mongo.tar.gz @ADDRESS_MACHINE_DE_TRAVAILLE:/tmp |
On mette les données dans la base
cd /tmp tar xvzf mongo.tar.gz -C /var/lib/mongo |
Vérifier les droits unix et les fichiers dans /var/lib/mongo
ls -als /var/lib/mongo |
On redémarre mongo et on vérifie les données dedans avec le fichier db_info.info que l'on a crée précédemment
service mongod start
mongo shinken --quiet --eval 'db.getCollectionNames()'
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));'
mongo shinken --quiet --eval 'db.getCollection("sla_archive").count();' |
Vider la base et redémarrer Shinken
cd /var/lib/mongo rm -fr * service mongod start service shinken start |
On peut supprimer les données SLA trop veilles si l'on avait pas mis en place la rotation des SLA
Pour s'assurer que le format de données est WiredTiger, il faut que l'entrée suivante soit dans le fichier /etc/mongod.conf:
ATTENTION: le fichier /etc/mongod.conf doit être dans le nouveau format de configuration (du yaml). Si la chaine wiredTiger n'est pas présente (et commentée) alors c'est que vous avez l'ancien format, et devez migrer vos paramètres. Pour ce faire, vous avez le fichier /etc/mongod.conf.rpmnew qui est présent avec le nouveau format, vous n'avez qu'à:
|
storage:
engine: wiredTiger |
Puis relancer la base:
/etc/init.d/mongod start |
Ensuite il faut lancer l'import, qui va se faire avec le nouveau format de données, et avec un espace disque consommé minimal:
shinken-restore |