Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue


Panel
titleSommaire

Table of Contents
stylenone



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

Warning
titleImportant !

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 Après la version 3, MongoDB propose une nouveau moteur de stockage de données appelé WiredTiger, qui permet d'avoir de meilleures performances et un espace disque consommé plus faible avec moins de fragmentation et une compression de donnée.

Il y a 2 situations ou vous aurez à utiliser la procédure de migration de MMapV1 vers WiredTiger:

  • Si vous avait installé votre Shinken à partir d'une version ANTÉRIEUR à la V02.06.00.
    • Le format de stockage était alors MMapV1.
  • Si vous faites un shinken-restore d'une configuration sauvegardé sur un Shinken au format MMap1.
    • La sauvegarde des données
.
1) Préparation
    • de MongoDB garde le format de stockage.

Quel format de donnée votre MongoDB utilise ?

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

Code Block
themeEmacs
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 n'avez pas besoin de continuer cette procédure.


Préparation

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 des données sont bien présentesla migration de donnée s'est bien passé.

Code Block
themeEmacs
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.

Info

Si aucune commande ne retourne de valeurs, il faut vérifier que vous êtes 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
themeEmacs
service shinken stop

2) Migration de la base


Enlever ce qui est inutile

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 PageScript
  • Utiliser le script
  • shinken-sla-delete-until
    • Son fonctionnement est décrit dans la page suivante : 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
themeEmacs
shinken-sla-delete-until --nb-day=365

--nb-day=365

:

Pour

garder

365

jours

de

données

SLA
Modifier

  • Si vous réduisez le nombre de jours stockés en utilisant le script, changez 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
    • Cela évitera que de nouveaux jours inutiles soit garder en base.
    • Référez-vous à la page de configuration du module SLA pour plus de d'information ( voir Module SLA ).
    • Note : Il n'est nécessaire de redémarrer Shinken maintenant, ce sera fait plus tard dans la procédure.

Migration de

mmapv1 à wiredTiger

la base

Il faut éteindre Shinken pour continuer la procédure

Code Block
themeEmacs
service shinken stop



Warning
titleImportant !

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 :

Code Block
themeEmacs
cd /tmp
mongodump -d shinken 
mongodump -d event_container
mongodump -d synchronizer


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

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


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

Code Block
languageyml
themeEmacs
storage:
     engine: wiredTiger

Démarrer Mongo

Code Block
themeEmacs
service mongod start

Vérifier le type de moteur de stockage :

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

Le retour de la commande doit être wiredTiger

On restaure les données dans MongoDB

Code Block
themeEmacs
cd /tmp
mongorestore dump


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

Info

Si vous avez utilisé le script shinken-sla-delete-until, le nombre de sla_archive doit avoir changé.



Code Block
themeEmacs
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
themeEmacs
service shinken start