| 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 | false |
|---|
|
|
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.
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 il n'est pas 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 des statistiques de la base de données qui vont servir plupart à vérifier que la 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 |
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.
| Info |
|---|
Si aucune commande ne retourne de valeurs, il faut vérifier que 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 |
| 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 :
| Code Block |
|---|
|
cd /tmp
mongodump -o 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 :
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.
| Warning |
|---|
|
Avant toute opération, faite un shinken-backup complet du serveur impacté ou avec les options qui permet de sauvegarder données |
Récupérer l'espace disque
Deux méthodes options existent pour le compactage de la base :
- Compactage in-place de la base
- Faire une sauvegarde de la base et restauration dans une autre base
La première option ne nécessite pas le montage d'une autre base ni de transfert de données. C'est globalement plus simple, mais pendant que la base se compacte elle devient indisponible, ce qui peut provoquer un long temps d'indisponibilité. De plus, suivant le moteur de base utilisé les contraintes et les résultats sont variables:
- MMapV1: le compactage sera efficace en termes de récupération d'espace, mais pendant le compactage, le double du volume de données sera utilisé, il faut donc prévoir assez d'espace disque
- Wired Tiger: le compactage est moins efficace, le moteur n'arrivant pas à récupérer tout l'espace perdu, mais par contre il se fait in-place sans consommer plus d'espace disque
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).
- Le script de vérification de la fragmentation permet de donner le moteur de données utilisé.
- Par contre, l'opération nécessitera un arrêt de la base mongoDB, donc vous devrez planifier une interruption de votre supervision.
Méthode 1 : Compactage dans la base
Il est important de noter que pendant que le script va fonctionner, la base se bloquer et les opérations ne pourront pas se faire. Nous vous conseillons de faire cette opération avec Shinken éteint.
Le script de compactage est launch_mongo_compaction.py
| Code Block |
|---|
Attention: ce script ne fonctionne que sur un shinken supérieur à la v02.07.00 |
Il se lance de la manière suivante:
| Code Block |
|---|
|
launch_mongo_compaction.py -H IP_SERVER --ssh-user=shinken --connection-method=ssh --ssh-keyfile=~shinken/.ssh/id_rsa |
- -H: adresse publique du serveur à vérifier
- ou localhost si vous souhaitez vérifier le serveur sur lequel s'exécute le script
- --connection-method=ssh: à n'utiliser que pour les serveurs distants afin de créer un tunnel SSH vers le serveur et protéger les accès
- --ssh-user: utilisateur à utiliser pour les serveurs distants pour les connexions SSH
- --ssh-keyfile: clé SSH à utiliser pour les serveurs distants
| Info |
|---|
ATTENTION: Pour rappel, lancer cette commande va bloquer la base pendant l'opération, qui va dépendre de la vitesse du serveur, notamment de la vitesse de ses disques, car toutes les données vont être lues/réécrites. Il faut que Shinken soit arrêté pendant cette opération. |
Au lancement, il va parcourir les bases de données, et va les compacter. Voici une exécution du script:
Image Removed
Pour information, la base de données de ce lancement faisait 600Mo sur disque pour un volume de données en base de 1.5Go.
Méthode 2: sauvegarde/restauration de la base dans une autre base de donnée, migration de MMapV1 vers Wired Tiger si nécessaire
| Info |
|---|
| Il est important de noter que pendant la restauration des données, il ne faut pas que Shinken fonctionne. Cette opération doit donc se faire à froid. |
C'est également la méthode pour migrer de moteur de données au sein d'un serveur: mongo ne supporte pas de changer de moteur in-place, il faut donc procéder à une restauration de données dans une nouvelle base avec le nouveau moteur.
Afin de sauvegarder la base, il faut prévoir suffisamment d'espace disque. Il faut ensuite lancer:
| Code Block |
|---|
|
shinken-backup --addons --configuration --sla --user |
Restauration sur un nouveau serveur
Il faut ensuite transférer la sauvegarde sur le nouveau serveur et lancer la restauration:
| Code Block |
|---|
|
shinken-restore |
Restauration sur le même serveur
Si vous souhaitez réutiliser le même serveur, il va falloir:
- Arrêter mongo
- Supprimer ses données
- S'assurer que le format de données est bien WiredTiger
- Restaurer les données
Arrêter MongoDB:
| Code Block |
|---|
|
/etc/init.d/mongod stop |
Supprimer les données:
| Code Block |
|---|
|
rm -rf /var/lib/mongo/* |
Migration vers Wired Tiger (si nécessaire)
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:
| Info |
|---|
| title | Le format du fichier mongod.conf doit être le nouveau format de mongo |
|---|
|
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'à: - sauvegarder votre ancien fichier
- copier le fichier /etc/mongod.conf.rpmnew en /etc/mongod.conf
- reportez vos paramètres spécifiques si vous en aviez modifiés
|
| Code Block |
|---|
|
storage:
engine: wiredTiger |
Puis relancer la base:Démarrer Mongo
| Code Block |
|---|
| language | bashtext |
|---|
| theme | Emacs |
|---|
|
/etc/init.d/service 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:
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 restaure les données dans MongoDB
| Code Block |
|---|
|
cd /tmp
mongorestore data_to_migrate |
On vérifie les données dedans avec le fichier db_info.info que l'on a créé précédemment.
| Code Block |
|---|
|
mongo shinken --quiet --eval 'db.getCollectionNames()'
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));' |
Démarrer Shinken
| Code Block |
|---|
|
service shinken start |
| Code Block |
|---|
|
shinken-restore |