Il y a eu une confusion considérable sur la récupération d'espace dans MongoDB, et certaines pratiques recommandées sont carrément dangereuses à faire dans certains types de déploiement. Plus de détails ci-dessous:
TL; DR repairDatabase tente de récupérer les données d'un déploiement MongoDB autonome qui tente de récupérer après une corruption de disque. S'il récupère de l'espace, c'est purement un effet secondaire . La récupération d'espace ne devrait jamais être la principale considération de l'exécution repairDatabase.
Récupérer de l'espace dans un nœud autonome
WiredTiger: Pour un nœud autonome avec WiredTiger, l'exécution compactlibère de l'espace pour le système d'exploitation, avec une mise en garde: la compactcommande sur WiredTiger sur MongoDB 3.0.x a été affectée par ce bogue: SERVER-21833 qui a été corrigé dans MongoDB 3.2.3. Avant cette version, compactsur WiredTiger pouvait échouer silencieusement.
MMAPv1: en raison du fonctionnement de MMAPv1, il n'existe aucune méthode sûre et prise en charge pour récupérer de l'espace à l'aide du moteur de stockage MMAPv1. compactdans MMAPv1 défragmentera les fichiers de données, rendant potentiellement plus d'espace disponible pour les nouveaux documents, mais cela ne libérera pas d'espace pour le système d'exploitation.
Vous pourrez peut- être exécuter repairDatabasesi vous comprenez parfaitement les conséquences de cette commande potentiellement dangereuse (voir ci-dessous), carrepairDatabase réécrit essentiellement toute la base de données en supprimant les documents corrompus. En tant qu'effet secondaire, cela créera de nouveaux fichiers de données MMAPv1 sans aucune fragmentation et libèrera de l'espace sur le système d'exploitation.
Pour une méthode moins aventureuse, l'exécution mongodumpet mongorestorepeut être également possible dans un déploiement MMAPv1, sous réserve de la taille de votre déploiement.
Récupérer de l'espace dans un jeu de réplicas
Pour les configurations de jeux de réplicas, la méthode la meilleure et la plus sûre pour récupérer de l'espace consiste à effectuer une synchronisation initiale , pour WiredTiger et MMAPv1.
Si vous devez récupérer de l'espace sur tous les nœuds de l'ensemble, vous pouvez effectuer une synchronisation initiale progressive. Autrement dit, effectuez une synchronisation initiale sur chacun des secondaires, avant de finalement abandonner le primaire et d'effectuer une synchronisation initiale sur celui-ci. La méthode de synchronisation initiale continue est la méthode la plus sûre pour effectuer la maintenance du jeu de réplicas, et elle n'implique pas non plus de temps d'arrêt en prime.
Veuillez noter que la faisabilité d'une synchronisation initiale progressive dépend également de la taille de votre déploiement. Pour les déploiements extrêmement volumineux, il peut ne pas être possible d'effectuer une synchronisation initiale et vos options sont donc un peu plus limitées. Si WiredTiger est utilisé, vous pourrez peut- être retirer un secondaire de l'ensemble, le démarrer de manière autonome, l'exécuter compactet le rejoindre dans l'ensemble.
En ce qui concerne repairDatabase
Veuillez ne pas exécuter repairDatabasesur les nœuds du jeu de réplicas . Ceci est très dangereux, comme mentionné dans la page RepairDatabase et décrit plus en détail ci-dessous.
Le nom repairDatabaseest un peu trompeur, car la commande ne tente de rien réparer. La commande était destinée à être utilisée en cas de corruption du disque sur un nœud autonome , ce qui pourrait entraîner la corruption de documents.
La repairDatabasecommande pourrait être plus précisément décrite comme «base de données de récupération». Autrement dit, il recrée les bases de données en supprimant les documents corrompus pour tenter de mettre la base de données dans un état où vous pouvez la démarrer et en récupérer le document intact.
Dans les déploiements MMAPv1, cette reconstruction des fichiers de base de données libère de l'espace pour le système d' exploitation en tant qu'effet secondaire . Libérer de l'espace sur le système d'exploitation n'a jamais été le but.
Conséquences repairDatabasesur un jeu de répliques
Dans un jeu de répliques, MongoDB s'attend à ce que tous les nœuds de l'ensemble contiennent des données identiques. Si vous exécutez repairDatabasesur un nœud de jeu de réplicas, il est possible que le nœud contienne une corruption non détectée et repairDatabasesupprime consciencieusement les documents corrompus pour vous.
De manière prévisible, cela fait que ce nœud contient un ensemble de données différent du reste de l'ensemble. Si une mise à jour atteint ce seul document, l'ensemble peut planter.
Pour aggraver les choses, il est tout à fait possible que cette situation reste en sommeil pendant une longue période, seulement pour frapper soudainement sans raison apparente.
