Gérer et libérer de l'espace disque dans les déploiements MongoDB

Les problèmes d'espace disque MongoDB se manifestent généralement de deux manières : le système de fichiers est presque plein, ou MongoDB semble volumineux même après avoir supprimé des données. Ce deuxième cas surprend de nombreuses équipes car WiredTiger peut réutiliser l'espace libéré en interne sans le restituer immédiatement au système d'exploitation.

Votre objectif est de faire la différence entre une croissance réelle, un espace libre interne réutilisable, des index surdimensionnés et une fragmentation nécessitant une fenêtre de maintenance.

Vérifier l'utilisation du disque au niveau de l'hôte

Commencez par le système de fichiers qui contient le dbPath de MongoDB. MongoDB ne peut pas continuer à écrire en toute sécurité si ce volume est plein.

df -h /var/lib/mongodb

Vérifiez également quels répertoires grossissent :

du -sh /var/lib/mongodb/* | sort -h

Utilisez votre dbPath réel ; /var/lib/mongodb est courant sur les paquets Linux mais pas universel.

Vérifier les métriques de stockage MongoDB

Dans mongosh, comparez la taille logique des données avec la taille de stockage allouée.

use myDatabase
db.stats()

Les champs utiles incluent :

dataSize : Taille logique des données des documents.
storageSize : Espace alloué pour les données de la collection.
indexSize : Espace utilisé par les index.

Pour une collection spécifique :

db.orders.stats({ scale: 1024 * 1024 })

Examinez size, storageSize et totalIndexSize. Si storageSize est beaucoup plus grand que size, la collection peut avoir un espace libre interne réutilisable provenant des mises à jour et suppressions. Si totalIndexSize est grand, les index peuvent être le moyen le plus rapide de réduire l'utilisation du disque.

Causes courantes de la croissance du disque MongoDB

Un taux élevé de suppressions et de mises à jour peut laisser un espace libre interne dans les fichiers WiredTiger. MongoDB réutilisera souvent cet espace pour les futures écritures, mais le système d'exploitation peut toujours afficher les fichiers comme volumineux.

Les index peuvent également consommer une grande partie du disque. Les index composés, les index de texte, les index génériques et les index en double s'accumulent rapidement.

Les lacunes de rétention sont une autre cause courante. Les collections de logs, sessions, événements et audits grossissent indéfiniment à moins que vous n'archiviez ou n'expiriez les anciens documents.

Moyens sûrs de réduire la croissance future

La meilleure solution pour le disque est généralement d'empêcher une croissance illimitée.

Pour les données temporelles, créez un index TTL :

db.logEvents.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400 }
)

La suppression TTL est gérée par un moniteur en arrière-plan et n'est pas instantanée à la seconde près. C'est néanmoins un bon choix pour les logs, sessions et événements temporaires où le timing exact de suppression n'est pas critique.

Passez en revue les index avant d'en supprimer un :

db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])

$indexStats peut indiquer si un index a été utilisé depuis le démarrage du processus. Considérez cela comme un indice, pas une preuve. Un index de rapport mensuel peut sembler inutilisé pendant une semaine calme.

Supprimez un index confirmé inutilisé par son nom :

db.orders.dropIndex('customerId_1_createdAt_-1')

Récupérer de l'espace à partir des fichiers existants

La suppression de documents ne réduit généralement pas la taille des fichiers WiredTiger sur le disque. Pour rendre l'espace au système de fichiers, vous avez besoin d'une stratégie de réécriture ou de compactage.

Utiliser `compact` avec précaution

compact peut réécrire les données de la collection et des index pour réduire l'utilisation du disque. C'est gourmand en ressources et peut bloquer les opérations sur la collection concernée, selon votre version de MongoDB et votre déploiement.

db.runCommand({ compact: 'orders' })

Exécutez-le pendant une fenêtre de maintenance, testez-le d'abord et lisez la documentation pour votre version exacte de MongoDB. Sur les jeux de réplicas, de nombreuses équipes compactent un secondaire à la fois, le laissent rattraper son retard, puis font basculer ou permutent les membres si nécessaire.

Dump et restauration pour une fragmentation sévère

Pour des données gravement fragmentées, un dump suivi d'une restauration reconstruit proprement les fichiers de la collection. C'est perturbant si vous le faites sur place, alors planifiez des sauvegardes, des temps d'arrêt ou une migration basée sur les réplicas.

mongodump --db myDatabase --collection orders --out /backup/mongo-dump

Après avoir vérifié le dump et planifié la transition, restaurez dans l'environnement cible :

mongorestore --db myDatabase --collection orders \
  /backup/mongo-dump/myDatabase/orders.bson

Ne supprimez pas les données de production avant d'avoir une sauvegarde vérifiée et un plan de retour arrière.

Ce qu'il ne faut pas faire

Ne supprimez pas manuellement les fichiers WiredTiger, les journaux ou les fichiers de collection du système de fichiers. Cela pourrait corrompre la base de données.

Ne supposez pas que du et la taille logique MongoDB doivent correspondre. La compression, les index, l'espace libre interne et le comportement du système de fichiers affectent tous les chiffres.

Soyez prudent avec les anciens conseils sur la préallocation de type MMAPv1. Les déploiements MongoDB modernes utilisent généralement WiredTiger, et son comportement de stockage est différent.

Conclusion pratique

Lorsque l'utilisation du disque MongoDB semble anormale, mesurez d'abord l'hôte, puis les bases de données, les collections et les index. Utilisez les index TTL et l'archivage pour ralentir la croissance. Supprimez uniquement les index inutiles confirmés. Pour une véritable récupération d'espace sur le système de fichiers, planifiez un compact ou un workflow de dump et restauration au lieu de vous attendre à ce que les suppressions réduisent immédiatement la taille des fichiers.