Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Scroll Ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmlfalse
Panel
titleSommaire

Table of Contents
stylenone

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

L'idée est de faire la migration sur une autre machine : la machine de travaille pour limité l'interruption de service sur la prod 

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
titleImportant !

Avant toute opération, faite un shinken-backup complet du serveur impacté ou avec les options qui permet de sauvegarder données

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

Sur la machine de production vérifier que le type de moteur de stockage est bien mmapv1MMapv1 à l'aide de la commande suivante

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

Ensuite on récupère des stats de la base qui vont nous servir a vérifié que l'on a les données 

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

Faire un état des lieux

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
Code Block
languagetext
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 db

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

2) Déplacement de la base

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.

Migration de la base

Il faut éteindre Shinken pour continuer la procédure

Code Block
languagetext
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
languagetext
themeEmacs
cd /tmp
mongodump -o data_to_migrate

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

Code Block

Sur la machine de travaille vérifier que le type de moteur de stockage est bien mmapv1: 

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

Pour changer le moteur si ce n'est pas le bon, mettre dans le fichier /etc/mongod.conf

Code Block
languageyml
themeEmacs
storage:
     engine: mmapv1

et supprimer les données dans la base puis reboot mongod:

Code Block
themeEmacs
service mongod stop
cd /var/lib/mongo
rm -fr *
service mongod start
mongo shinken  --quiet --eval "print(db.serverStatus().storageEngine.name)" --> mmapv1

Eteindre la base et la vide pour préparé la base a récupère les données de la production

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

Sur la machine de production

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

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

Code Block
themeEmacs
cd /var/lib/
tar cvzf mongo.tar.gz mongo/
scp mongo.tar.gz @ADDRESS_MACHINE_DE_TRAVAILLE:/tmp

Sur la machine de travaille :

On mette les données dans la base

Code Block
themeEmacs
cd /tmp
tar xvzf mongo.tar.gz mongo/
scp mongo.tar.gz @ADDRESS_MACHINE_DE_TRAVAILLE:/tmp

Restauration sur le même serveur

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

Code Block
languagetext
themeEmacs
storage:
     engine: wiredTiger

Démarrer Mongo

Code Block
languagetext
themeEmacs
service mongod start

Vérifier le type de moteur de stockage :

Code Block
languagetext
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
languagetext
themeEmacs
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
languagetext
themeEmacs
mongo shinken --quiet --eval 'db.getCollectionNames()'
mongo shinken --quiet --eval 'printjson(db.adminCommand( { listDatabases: 1 } ));'


Démarrer Shinken

Code Block
languagetext
themeEmacs
service shinken start

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
themeEmacs
/etc/init.d/mongod stop

Supprimer les données:

Code Block
themeEmacs
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
titleLe 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
languageyml
themeEmacs
storage:
     engine: wiredTiger

Puis relancer la base:

Code Block
languagebash
themeEmacs
/etc/init.d/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:

Code Block
languagebash
themeEmacs
shinken-restore