| Scroll Ignore |
|---|
| scroll-viewport | true |
|---|
| scroll-pdf | true |
|---|
| scroll-office | true |
|---|
| scroll-chm | true |
|---|
| scroll-docbook | true |
|---|
| scroll-eclipsehelp | true |
|---|
| scroll-epub | true |
|---|
| scroll-html | truefalse |
|---|
|
|
La Le moteur de 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 .
| Warning |
|---|
|
Avant toute opération, faites un shinken-backup complet ( ou avec les options qui permettent de sauvegarder les données ) du serveur impacté |
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.
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.
Vérifier que le type de moteur de stockage est bien MMapv1 à l'aide de la commande suivante :
| Code Block |
|---|
|
mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" |
Le retour de la commande doit être MMapv1.
| Tip |
|---|
| Si le retour est wiredTiger, alors la base de données est déjà migrée et |
vous avez besoin de | nécessaire de continuer cette procédure. |
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 ).
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 des données sont bien présentesla migration de donnée s'est bien passé.
| Code Block |
|---|
|
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 l'architecture, il est possible que des commandes ne retournent rien. Si par exemple vous exécutez , pour exécuter ces commandes sur un serveur qui héberge uniquement la base du Synchronizer, alors seul la deuxième commande vous retournera des valeurs.
| Info |
|---|
Si aucune commande ne retourne de valeurs, il faut vérifier que vous êtes si on est sur le bon serveur. Cette procédure changera bien le type du moteur de stockage, mais aucune donnée ne sera impactée. |
Il faut éteindre Shinken pour continuer la procédure
| Code Block |
|---|
|
service shinken stop |
Avant de faire la migration, il peut être intéressant de supprimer les anciennes données SLA afin de ne conserver que les données pertinentes. Cette étape est facultative :
| Include Page |
|---|
| Warning |
|---|
|
Avant toute opération, faites un shinken-backup complet ( ou avec les options qui permettent de sauvegarder les données ) du serveur impacté. |
On sauvegarde les données de Shinken :
Script shinken-sla-delete-until | Script shinken-sla-delete-until | On peut supprimer les données SLA trop veilles si l'on n’avait pas mis en place la rotation des SLA
| Code Block |
|---|
|
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 :
code |
cd /tmp
mongodump -d shinken -c sla_archive
mongodump -d event_container -c ec_dataso data_to_migrate |
On éteint la base de données et on la vide
| Code Block |
|---|
|
service mongod stop
cd /var/lib/mongo
rm -fr * |
Changer le moteur de mmapv1 à wiredTiger. Mettre à jour le fichier /etc/mongod.conf :
| Code Block |
|---|
| language | ymltext |
|---|
| theme | Emacs |
|---|
|
storage:
engine: wiredTiger |
Démarrer Mongo
| Code Block |
|---|
|
service mongod start |
Vérifier le type de moteur de stockage :
| Code Block |
|---|
|
mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" |
Le retour de la commande doit être wiredTiger
On démarre mongo et on On restaure les données dedansdonnées dans MongoDB
| Code Block |
|---|
|
cd /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
| Code Block |
|---|
|
code |
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
| Code Block |
|---|
|
service shinken start |