Gestione e Liberazione dello Spazio su Disco nelle Distribuzioni MongoDB
Monitora l'uso del disco di MongoDB, trova collezioni e indici sovradimensionati e recupera spazio in modo sicuro con TTL, compattazione o workflow di ripristino.
Gestione e Liberazione dello Spazio Disco nelle Deployments MongoDB
I problemi di spazio disco di MongoDB di solito si manifestano in due modi: il filesystem è quasi pieno, oppure MongoDB appare grande anche dopo aver eliminato i dati. Il secondo caso sorprende molti team perché WiredTiger può riutilizzare internamente lo spazio liberato senza restituirlo immediatamente al sistema operativo.
Il tuo obiettivo è distinguere tra crescita reale, spazio libero interno riutilizzabile, indici sovradimensionati e frammentazione che richiede una finestra di manutenzione.
Controlla l'Uso del Disco a Livello di Host
Inizia con il filesystem che contiene il dbPath di MongoDB. MongoDB non può continuare a scrivere in sicurezza se quel volume si riempie.
df -h /var/lib/mongodb
Controlla anche quali directory stanno crescendo:
du -sh /var/lib/mongodb/* | sort -h
Usa il tuo dbPath effettivo; /var/lib/mongodb è comune sui pacchetti Linux ma non universale.
Controlla le Metriche di Archiviazione di MongoDB
All'interno di mongosh, confronta la dimensione logica dei dati con la dimensione di archiviazione allocata.
use myDatabase
db.stats()
I campi utili includono:
dataSize: Dimensione logica dei dati dei documenti.storageSize: Spazio allocato per i dati della collezione.indexSize: Spazio utilizzato dagli indici.
Per una collezione specifica:
db.orders.stats({ scale: 1024 * 1024 })
Guarda size, storageSize e totalIndexSize. Se storageSize è molto più grande di size, la collezione potrebbe avere spazio libero interno riutilizzabile da aggiornamenti ed eliminazioni. Se totalIndexSize è grande, gli indici potrebbero essere il modo più rapido per ridurre l'uso del disco.
Cause Comuni della Crescita del Disco di MongoDB
Un alto tasso di eliminazioni e aggiornamenti può lasciare spazio libero interno nei file WiredTiger. MongoDB spesso riutilizzerà quello spazio per scritture future, ma il sistema operativo potrebbe ancora mostrare i file come grandi.
Anche gli indici possono consumare una grande parte del disco. Indici composti, indici di testo, indici wildcard e indici duplicati si accumulano rapidamente.
Le lacune di conservazione sono un'altra causa comune. Le collezioni di log, sessioni, eventi e audit crescono all'infinito a meno che non si archivino o si facciano scadere i vecchi documenti.
Modi Sicuri per Ridurre la Crescita Futura
La migliore soluzione per il disco è solitamente prevenire una crescita illimitata.
Per i dati basati sul tempo, crea un indice TTL:
db.logEvents.createIndex(
{ createdAt: 1 },
{ expireAfterSeconds: 86400 }
)
L'eliminazione TTL è gestita da un monitor in background e non è istantanea al secondo. È comunque una buona scelta per log, sessioni ed eventi temporanei dove la tempistica esatta di eliminazione non è critica.
Rivedi gli indici prima di eliminare qualsiasi cosa:
db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])
$indexStats può mostrare se un indice è stato utilizzato dall'avvio del processo. Trattalo come un indizio, non come una prova. Un indice per report mensili potrebbe sembrare non utilizzato in una settimana tranquilla.
Elimina un indice confermato come non utilizzato per nome:
db.orders.dropIndex('customerId_1_createdAt_-1')
Recupera Spazio dai File Esistenti
Eliminare documenti di solito non riduce i file WiredTiger sul disco. Per restituire spazio al filesystem, hai bisogno di una strategia di riscrittura o compattazione.
Usa compact con Cautela
compact può riscrivere i dati della collezione e degli indici per ridurre l'uso del disco. È intensivo in termini di risorse e potrebbe bloccare le operazioni sulla collezione interessata, a seconda della versione di MongoDB e del deployment.
db.runCommand({ compact: 'orders' })
Eseguilo durante una finestra di manutenzione, testalo prima e leggi la documentazione per la tua versione esatta di MongoDB. Sui set di repliche, molti team compattano un secondario alla volta, lo lasciano recuperare, e poi fanno il passo o ruotano i membri secondo necessità.
Dump e Ripristino per Frammentazione Grave
Per dati gravemente frammentati, un dump e ripristino ricostruisce i file della collezione in modo pulito. Questo è dirompente se lo fai sul posto, quindi pianifica backup, tempi di inattività o una migrazione basata su replica.
mongodump --db myDatabase --collection orders --out /backup/mongo-dump
Dopo aver verificato il dump e pianificato il cutover, ripristina nell'ambiente di destinazione:
mongorestore --db myDatabase --collection orders \
/backup/mongo-dump/myDatabase/orders.bson
Non eliminare i dati di produzione finché non hai un backup verificato e un piano di rollback.
Cosa Non Fare
Non eliminare manualmente i file WiredTiger, journal o di collezione dal filesystem. Questo può corrompere il database.
Non presumere che du e la dimensione logica di MongoDB debbano corrispondere. Compressione, indici, spazio libero interno e comportamento del filesystem influenzano tutti i numeri.
Fai attenzione ai vecchi consigli sulla preallocazione in stile MMAPv1. I deployment moderni di MongoDB usano tipicamente WiredTiger, e il suo comportamento di archiviazione è diverso.
Consiglio Pratico
Quando l'uso del disco di MongoDB sembra sbagliato, prima misura l'host, poi misura database, collezioni e indici. Usa indici TTL e archiviazione per rallentare la crescita. Elimina solo gli indici confermati come non necessari. Per un vero recupero di spazio sul filesystem, pianifica compact o un workflow di dump e ripristino invece di aspettarti che le eliminazioni riducano immediatamente i file.