Page History

L'idée est de faire la migration sur une autre machine : la machine de travail pour limiter l'interruption de service sur la production

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 le réduire.

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

1) Préparation

Concept

Le moteur de base de données d'origine de MongoDB, MMAPv1, ne supportait pas la compression des données, ce qui entraînait une consommation importante d’espace disque. Le moteur plus récent, WiredTiger, intègre nativement la compression, permettant ainsi de réduire significativement la taille de la base sur le disque. Passer à WiredTiger permet donc d'optimiser l'utilisation de l'espace de stockage.

Préparation

Quel format de donnée le MongoDB utilise ?

Vérifier que le type de moteur de stockage est bien mmapv1MMapv1 à l'aide de la commande suivante : 

mongo shinken  --quiet --eval "print(db.serverStatus().storageEngine.name)" --> mmapv1

Le retour de la commande doit être MMapv1.

Limiter les données sauvegardées en base

Plus la base de données contient de données, plus la migration vers un nouveau moteur de données prendra du temps, notamment en raison du processus de sauvegarde et de restauration des données. Pour cette raison, il peut être judicieux de limiter les données stockées en base avant de procéder à la migration ( voir la page MongoDB - Méthode 1 : Ne garder que les données pertinentes ).

Faire un état des lieux

En premier lieu, il est important de récupérer Ensuite on récupère des statistiques de la base de données qui vont nous servir plupart à vérifier que l'on a les donnéesla migration de donnée s'est bien passé.

mongo shinken --quiet --eval 'db.getCollectionNames()' | tee db_info.info
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));' | tee -a db_info.info
mongo shinken --quiet --eval 'db.getCollection("sla_archive").count();' | tee db_info.info

2) Déplacement de la base

Ces commandes vont afficher et conserver dans le fichier db_info.info respectivement :

• La liste des collections de la base shinken dans une chaîne de caractères séparée par des virgules.
• La liste des bases présentes sur le serveur de production, dans un format JSON.

En fonction de l'architecture, il est possible que des commandes ne retournent rien. Si par exemple, pour exécuter ces commandes sur un serveur qui héberge uniquement la base du Synchronizer, alors seul la deuxième commande retournera des valeurs.

Migration de la base

Il faut éteindre Shinken pour continuer la procédure

service shinken stop

On sauvegarde les données de Shinken :

cd /tmp
mongodump -o data_to_migrate

On éteint la base de données et on la vide

2) Migration de la base

Sur la machine de travail

On peut supprimer les données SLA trop veilles si l'on avait pas mis en place la rotation des SLA

/var/lib/shinken/libexec/tools/shinken-delete-sla --nb-day=365 --> Pour garder 365 jours de donnée SLA

Sur la machine de production

Modifier le paramètre nb_stored_days du module sla, par défaut dans /etc/shinken/modules/sla.cfg pour mettre le même nombre de jour que mis précédemment.

Note : Il n'est nécessaire de redémarrer Shinken maintenant se sera fait plus tard dans la procédure.

Sur la machine de travail

On dump les données d'archive SLA et la base des events.

mongodump -d shinken -c sla_archive 
mongodump -d event_container -c ec_datas

Eteindre la base et la vider

service mongod stop
cd /var/lib/mongo
rm -fr *

Changer le moteur pour wiredTigerde mmapv1 à wiredTiger. Mettre dans à jour le fichier fichier /etc/mongod.conf :

storage:
     engine: wiredTiger

Redémarrer mongoDémarrer Mongo

service mongod start

Vérifier que le type de moteur de stockage est bien wiredTiger : 

mongo shinken  --quiet --eval "print(db.serverStatus().storageEngine.name)" --> wiredTiger

Le retour de la commande doit être wiredTiger

On restaure les données dans MongoDB

On redémarre mongo et on restaure les donnée dedant

service mongod startcd /tmp
mongorestore dumpdata_to_migrate

On vérifie les données dedans avec le fichier dbfichier db_info.info que l'on a crée créé précédemment.

Note : le nombre de sla_archive doit avoir changer vus que on en a supprimé et il ne doit rester qu'une collection : sla_archive 

mongo shinken --quiet --eval 'db.getCollectionNames()' 
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));' 
mongo shinken --quiet --eval 'db.getCollection("sla_archive").count();' 

Eteindre Shinken, Eteindre mongo, copier les données sur la machine de production.

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 mongo stop
cd /var/lib/
tar cvzf mongo.tar.gz mongo/
scp mongo_wiredTiger.tar.gz @ADDRESS_MACHINE_DE_PRODUCTION:/tmp

Démarrer Shinken

Sur la machine de production

On coupe Shinken. on supprime les archives SLA et les events, on dump la base

service shinken stop
mongo shinken --quiet --eval 'db.sla_archive.drop()'
mongo event_container --quiet --eval 'db.ec_datas.find({event_since: {"$gte": new Date("2021-04-12 12:00:00.000Z")}}).forEach(function(docs){db.ec_datas_backup_migration_mongo_engine.insert(docs);})' <-- Mettre la date et l'heurs du transfert sur la machine de travaille (date du mongo.tar.gz) 
mongo event_container --quiet --eval 'db.ec_datas.drop()'
mongodump 

Eteindre la base et la vider

service mongod stop
cd /var/lib/mongo
rm -fr *

Changer le moteur pour wiredTiger. Mettre dans le fichier /etc/mongod.conf :

storage:
     engine: wiredTiger

Copier les données de /tmp/mongo_wiredTiger.tar.gz dans /var/lib/mongo

cd /tmp
tar xvzf mongo_wiredTiger.tar.gz -C /var/lib/mongo

Vérifier les droits unix et les fichiers dans /var/lib/mongo

ls -als /var/lib/mongo

Redémarrer mongo

service mongod start

Vérifier que le type de moteur de stockage est bien wiredTiger: 

mongo shinken  --quiet --eval "print(db.serverStatus().storageEngine.name)" --> wiredTiger

Et restaurer les données de production

mongorestore dump