Page History

La base de données va se fragmenter au fil des insertions/suppressions d'éléments et le volume des données va devenir plus faible que l'espace disque consommé ( dans /var/lib/mongo ). Il est possible de surveiller cet écart de consommation et même le réduire grâce au check .

Il est fortement recommandé de migrer sur le moteur WiredTiger, qui permet d'avoir de meilleures performances et un espace disque consommé plus faible avec moins de fragmentation et une compression de données.

1) Préparation

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

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

Le retour de la commande doit être MMapv1. Si le retour est wiredTiger, alors la base de données est déjà migrée et vous n'avez pas besoin de continuer cette procédure.

Ensuite on récupère des statistiques de la base de données qui vont nous servir à vérifier que des données sont bien présentes.

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 -a db_info.info

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.
• Le nombre d'archives SLA présente sur le serveur de production.

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

Il faut éteindre Shinken pour continuer la procédure

service shinken stop

2) Migration de la base

Avant de faire la migration, il peut être intéressant de supprimer les anciennes données SLA. Cette étape est facultative :

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

shinken-sla-delete-until --nb-day=365

--nb-day=365 : Pour garder 365 jours de données SLA

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 jours que mis précédemment.

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

Migration de mmapv1 à wiredTiger

On dump les données d'archive SLA et la base de données des évènements :

cd /tmp
mongodump -d shinken -c sla_archive
mongodump -d event_container -c ec_datas

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

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

Changer le moteur de mmapv1 à wiredTiger. Mettre à jour le fichier /etc/mongod.conf :

storage:
     engine: wiredTiger

Démarrer Mongo

service mongod start

Vérifier le type de moteur de stockage :

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

Le retour de la commande doit être wiredTiger

On démarre mongo et on restaure les données dedans

cd /tmp
mongorestore dump

On vérifie les données dedans avec le fichier db_info.info que l'on a crée 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();'

Démarrer Shinken

service shinken start