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.

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.