ApsaraDB for MongoDB:Récupération des fragments de disque pour libérer de l'espace

Quelle situation rencontrez-vous ?

Utilisez le tableau suivant pour identifier rapidement votre situation et accéder à la section correspondante :

Conditions de déclenchement et règles

Le système récupère automatiquement les fragments uniquement des collections qui remplissent simultanément les conditions suivantes :

• La taille combinée de l'espace d'indexation et de l'espace de données dépasse 1 Go.

• Le taux de fragmentation dépasse 20 %.

Règles supplémentaires :

• La limite supérieure pour un seul cycle de récupération est de 100 Go. Tout excédent est récupéré lors des cycles suivants.

• Seuls les nœuds Hidden sont concernés par la récupération. Les nœuds Hidden ne traitent pas le trafic métier, donc la récupération n'affecte pas les nœuds primary ou secondary.

• Les seuils mentionnés ci-dessus sont intégrés au système et ne peuvent pas être personnalisés.

Point d'accès à la configuration

1. Connectez-vous à la console MongoDB et accédez à l'instance cible.

2. Dans le volet de navigation de gauche, sélectionnez CloudDBA > Storage Analysis.

3. Dans la liste Data Space, localisez la colonne Fragmentation Rate et cliquez sur le lien Recycle.

4. Dans la boîte de dialogue Fragment Recycling Plan qui s'affiche, cliquez sur Create Plan et confirmez.

Procédure

1. Accédez à l'instance cible. Dans le volet de navigation de gauche, sélectionnez CloudDBA > Storage Analysis.

2. Dans la liste Data Space, consultez le taux de fragmentation et l'espace récupérable pour chaque collection.

   Important

   Les opérations de récupération dans l'analyse du stockage de la console, ainsi que le taux de fragmentation et l'espace récupérable affichés sur la page, ciblent par défaut les nœuds Hidden.

3. Pour les collections présentant des taux de fragmentation élevés que vous souhaitez récupérer, cliquez sur le bouton Recycle correspondant pour lancer l'exécution.

Vérifier la réussite de la récupération

Une fois la récupération terminée, exécutez à nouveau l'analyse du stockage et vérifiez si le taux de fragmentation de la collection cible a diminué. Assurez-vous de consulter le même nœud sur lequel la récupération a été effectuée (voir FAQ et dépannage).

Exigences en matière d'autorisations

L'exécution de la commande compact nécessite que le compte dispose des autorisations dbAdmin ou hostManager (version > 8.0). Sinon, une erreur d'autorisation sera signalée :

not authorized on <database> to execute command { compact: ... }

Impact de compact sur les charges de travail

• Blocage des lectures/écritures et impact sur les performances

  • Avant MongoDB 4.4 : La commande compact verrouille la base de données contenant la collection, bloquant toutes les opérations de lecture et d'écriture sur cette base de données. Lorsque la fragmentation est sévère, compact peut prendre beaucoup de temps pour se terminer, ce qui peut entraîner un retard de réplication sur les nœuds Hidden. Nous vous recommandons de l'exécuter pendant les heures creuses, d'augmenter la taille de l'oplog en fonction de votre charge d'écriture ou de Mettre à niveau la version majeure de la base de données vers MongoDB 4.4 ou une version ultérieure avant de récupérer les fragments.

  • MongoDB 4.4 et versions ultérieures : La commande compact ne bloque plus les opérations de lecture et d'écriture, mais peut affecter les performances pendant l'exécution. Nous vous recommandons de l'exécuter pendant les heures creuses.

• Reconstruction du nœud

  • MongoDB 3.4 (toutes versions), MongoDB 4.0 (toutes versions), MongoDB 4.2 versions mineures anciennes (4.0.22 ou antérieure) et MongoDB 4.4 versions mineures anciennes (5.0.6 ou antérieure) : Le nœud exécutant compact passe à l'état RECOVERING. Si cet état persiste trop longtemps, le composant de contrôle de santé peut signaler le nœud comme étant sain et déclencher une reconstruction automatique. Pour plus d'informations sur les versions de MongoDB, consultez Versions mineures de MongoDB.

  • Pour les instances exécutant des versions ultérieures : Le nœud exécutant compact reste à l'état SECONDARY et ne déclenche pas de reconstruction.

• Quelle que soit la version, privilégiez toujours la récupération des fragments depuis les nœuds Hidden ou Secondary afin d'éviter d'impacter le nœud primary. Avant de récupérer les fragments de disque, nous vous recommandons de sauvegarder votre base de données.

Durée d'exécution de compact

La durée d'exécution dépend du volume de données, de la charge du système et d'autres facteurs, et ne peut pas être estimée avec précision. Les collections plus volumineuses avec une fragmentation plus importante prennent plus de temps. Les très grandes collections (plusieurs centaines de Go) peuvent prendre considérablement plus de temps. Nous vous recommandons d'utiliser dryRun: true pour estimer d'abord l'espace récupérable, et d'exécuter l'opération pendant les heures creuses.

Les données suivantes sont fournies à titre indicatif uniquement :

Test réel (MongoDB 4.4) : L'exécution de compact sur une collection d'environ 2,5 Go avec une fragmentation de 50 % a pris environ 5 secondes et a libéré environ 1,9 Go d'espace.

Scénarios où compact est inefficace

Les scénarios suivants peuvent rendre la commande compact inefficace :

• La taille physique de la collection est inférieure à 1 Mo.

• Le taux de fragmentation est inférieur à 20 %.

• Moins de 20 % d'espace libre existe dans les 80 % premiers du fichier, ou moins de 10 % d'espace libre existe dans les 90 % premiers du fichier.

Pour plus d'informations, consultez block_compact.

Instances Replica Set

Connectez-vous à un nœud Secondary et exécutez les commandes suivantes :

use <database>

// Before reclamation: check database space usage for comparison
db.stats()

// Dry run: estimate reclaimable space without actually reclaiming
db.runCommand({ compact: "<collection>", dryRun: true })

// Actual reclamation
db.runCommand({ compact: "<collection>" })

// After reclamation: check again to compare space
db.stats()

Le paramètre dryRun: true active le mode dry run, qui renvoie uniquement estimatedBytesFreed (le nombre estimé d'octets pouvant être libérés) sans modifier aucun fichier. Après avoir examiné les résultats du dry run, supprimez ce paramètre et exécutez la récupération réelle. Exécutez db.stats() avant et après la récupération pour comparer l'utilisation de l'espace de la base de données et confirmer le résultat.

will not run compact on an active replica set primary as this will slow down
other running operations. use force:true to force

Instances Sharded Cluster

Pour les clusters shardés, vous devez uniquement récupérer les fragments des nœuds correspondants dans le composant Shard. Les composants Mongos et ConfigServer ne stockent pas de données utilisateur et ne nécessitent pas de récupération.

Les nœuds en lecture seule dans les clusters shardés ne prennent pas en charge la commande compact , vous ne pouvez donc pas récupérer les fragments des nœuds en lecture seule (ReadOnly).

Récupération des fragments des nœuds Secondary : Lors de l'exécution de runCommandOnShard, vous devez définir la préférence de lecture sur Secondary. La syntaxe varie selon le client. Sélectionnez la méthode appropriée pour votre client :

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"}},{readPreference: "secondary"})

db.getMongo().setReadPref('secondary')
db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"}})

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"},$queryOptions: {$readPreference: {mode: 'secondary'}}})

Récupération des fragments des nœuds Primary (non recommandé) :

db.adminCommand({
  runCommandOnShard: "<shardId>",
  dbName: "<database>",
  command: { compact: "<collection>", force: true }
})

Récupération exécutée mais sans effet visible

Vérifiez les points suivants dans l'ordre :

1. Incompatibilité de nœud entre l'opération et la vérification (cause la plus fréquente) : L'analyse du stockage de la console récupère les fragments des nœuds Hidden, et la page affiche par défaut le taux de fragmentation des nœuds Hidden. La commande compact en ligne de commande affecte le nœud auquel vous êtes connecté. Si vous avez exécuté compact sur le nœud primary ou secondary mais que vous avez vérifié le taux de fragmentation dans l'analyse du stockage de la console, les chiffres ne changeront pas. Approche correcte : Accédez à la page Monitoring Information et basculez vers le nœud sur lequel vous avez réellement effectué l'opération pour afficher l'utilisation de l'espace disque.

2. Fragmentation interne des fichiers : compact ne peut tronquer que l'espace libre contigu à la fin d'un fichier. L'espace réutilisable au sein du fichier ne peut pas être récupéré. Si les fragments sont distribués à l'intérieur du fichier, l'espace disque peut rester presque inchangé après compact. Il s'agit d'un comportement attendu du moteur de stockage WiredTiger, et non d'un échec. Exécutez db.<collection>.stats() et vérifiez le ratio de freeStorageSize par rapport à storageSize pour estimer l'espace récupérable.

3. En dessous du seuil de récupération : Si le taux de fragmentation est inférieur à 20 %, si la taille physique de la collection est inférieure à 1 Mo ou si la collection est petite, l'espace récupérable absolu est très faible et la récupération peut n'avoir aucun effet visible.

4. Protection du nœud Primary ayant bloqué l'opération : Si vous voyez use force:true to force, il s'agit du mécanisme de protection indiquant que compact a été exécuté sur le nœud primary. N'utilisez pas force. Exécutez plutôt compact sur un nœud Hidden ou Secondary, ou utilisez l'analyse du stockage de la console pour récupérer les nœuds Hidden.

Pourquoi le taux de fragmentation ne tombe-t-il pas à 0 % ?

Il s'agit d'un comportement attendu. compact ne récupère que l'espace libre contigu à la fin d'un fichier. L'espace réutilisable au sein du fichier est préservé pour les écritures futures. Par conséquent, le taux de fragmentation ne peut généralement pas tomber à 0 %. Il s'agit d'un choix de conception du moteur de stockage WiredTiger.

Erreur : not authorized / Unauthorized

L'exécution de compact nécessite les autorisations dbAdmin ou hostManager (version > 8.0). Sinon, une erreur d'autorisation sera signalée. Voir Exigences en matière d'autorisations.

Erreur : Interrupted ... cache eviction pressure

Cause : Pendant l'exécution de compact, le moteur de stockage WiredTiger subit une pression d'éviction du cache. Les versions plus anciennes et les instances de petites spécifications disposent de ressources mémoire limitées. Lorsque la pression du cache devient trop élevée et que le moteur ne peut pas évacuer les pages à temps, compact est interrompu et se termine prématurément.

Résolution : Réessayez pendant les heures creuses, déclenchez un basculement primary/secondary et réessayez, ou mettez à niveau la spécification de l'instance avant de procéder à la récupération.

Puis-je exécuter compact lorsque l'instance est verrouillée en raison d'un disque plein ?

Oui. Lorsque le disque est plein, l'instance passe à un état verrouillé. Les opérations d'écriture (insert) et de suppression (delete) sont rejetées avec l'erreur cloud instance error, disk locked..., mais les opérations find, compact et drop peuvent toujours être exécutées.

Décision de récupération la plus rapide

L'utilisation dans la console ne correspond pas aux alertes (par exemple, la console affiche 60 % mais l'alerte se déclenche à 90 %)

Cela est dû à des dimensions d'affichage différentes, et non à une erreur de données :

• Les alertes se déclenchent sur le « nœud unique le plus élevé » : Dans un replica set, l'utilisation du disque des nœuds Primary, Secondary et Hidden peut différer (les nœuds Secondary/Hidden sont souvent plus élevés que Primary en raison de l'oplog, du timing de récupération, des fichiers temporaires et d'autres raisons). Une alerte se déclenche lorsqu'un seul nœud dépasse le seuil.

• La console n'affiche pas le « nœud le plus élevé » par défaut : La page Basic Information de l'instance affiche une valeur agrégée, et la page Storage Analysis affiche par défaut le nœud Hidden. Les deux peuvent être inférieurs au nœud qui a déclenché l'alerte.

Comment afficher l'utilisation réelle de chaque nœud : Accédez à la page Monitoring Information de l'instance, basculez le mode d'affichage sur Sub-node independent et vous pourrez afficher individuellement l'utilisation de l'espace disque de chaque nœud Primary / Secondary afin de trouver le nœud à forte utilisation qui a déclenché l'alerte.

Pour plus d'informations sur les raisons pour lesquelles l'utilisation du disque des nœuds primary et secondary diffère et comment y remédier, consultez Utilisation élevée de l'espace disque des instances ApsaraDB for MongoDB.

Puis-je réduire la taille du disque pour économiser de l'argent ?

La réduction de taille n'est pas prise en charge. ApsaraDB for MongoDB ne permet pas de réduire l'espace disque acheté, quelle que soit la version. Même si vous avez nettoyé une grande quantité de données et récupéré des fragments, vous ne pouvez que maintenir ou augmenter la spécification du disque. Vous ne pouvez pas la réduire directement.

Si vous avez besoin d'une spécification de disque plus petite, la seule option consiste à créer une nouvelle instance avec une spécification plus petite, à migrer vos données à l'aide de DTS, puis à libérer l'instance d'origine. Évaluez le coût de migration et la fenêtre d'interruption avant de procéder.

Pour les changements de configuration et les limites de spécification, consultez Modifier la configuration d'une instance replica set.

Pourquoi des fragments de disque apparaissent-ils ?

Lorsque des données sont supprimées via la commande delete ou par expiration TTL, elles sont uniquement marquées comme supprimées. L'espace qu'elles occupaient n'est pas immédiatement restitué au système d'exploitation. Au lieu de cela, il est conservé sous forme de blocs libres pour les écritures futures. Lorsque les suppressions dépassent les écritures, ces blocs libres restent inutilisés pendant de longues périodes, formant des fragments. C'est pourquoi l'utilisation du disque reste élevée même après la diminution du volume de données.

Quand récupérer les fragments de disque

Envisagez de récupérer les fragments de disque dans les situations suivantes :

• Après la suppression d'un grand volume de données : Lorsque vous supprimez un grand nombre de documents, l'espace libéré n'est pas restitué au système d'exploitation mais réservé pour les écritures futures, laissant un espace fragmenté important sur le disque.

  Important

  La suppression manuelle (delete) et l'expiration TTL ne récupèrent pas automatiquement les fragments de disque. Une récupération manuelle est nécessaire.

• Après des charges de travail d'écriture élevées prolongées : Des charges de travail d'écriture soutenues et élevées (insertions, mises à jour et suppressions fréquentes) accumulent progressivement de l'espace fragmenté sur le disque.

• Lorsque l'espace disque est faible et que la fragmentation dépasse 20 % : Lorsque l'utilisation du disque atteint 85 à 90 % ou plus, la récupération des fragments peut libérer de l'espace et réduire la pression sur le stockage.

Afficher et estimer l'espace récupérable

Connectez-vous à l'instance (pour les instances replica set, connectez-vous à un nœud Secondary pour minimiser l'impact sur le service) et exécutez db.runCommand({collStats: "<collection>"}) pour afficher l'état de stockage d'une collection. Prêtez attention aux champs suivants :

• size : La taille de stockage logique de la collection.

• storageSize : La taille de stockage physique de la collection.

• freeStorageSize : L'espace libre récupérable au sein de la collection (disponible dans MongoDB 4.4 et versions ultérieures).

Après la suppression de documents avec la commande remove, size diminue, mais storageSize peut ne pas changer. Un ratio plus élevé de freeStorageSize par rapport à storageSize indique un taux de fragmentation plus élevé.

Vous pouvez également exécuter la commande suivante pour estimer l'espace de fragments récupérable d'une collection (renvoie le nombre d'octets réutilisables) :

db.<collection>.stats().wiredTiger["block-manager"]["file bytes available for reuse"]