Verwalten und Freigeben von Speicherplatz in MongoDB-Bereitstellungen

MongoDB-Festplattenprobleme zeigen sich normalerweise auf zwei Arten: Das Dateisystem ist fast voll, oder MongoDB erscheint groß, selbst nachdem Sie Daten gelöscht haben. Der zweite Fall überrascht viele Teams, da WiredTiger freigegebenen Speicherplatz intern wiederverwenden kann, ohne ihn sofort an das Betriebssystem zurückzugeben.

Ihr Ziel ist es, den Unterschied zwischen echtem Wachstum, wiederverwendbarem internem freiem Speicherplatz, überdimensionierten Indizes und Fragmentierung zu erkennen, die ein Wartungsfenster erfordert.

Überprüfen der Festplattennutzung auf Host-Ebene

Beginnen Sie mit dem Dateisystem, das den dbPath von MongoDB enthält. MongoDB kann nicht sicher weiterschreiben, wenn dieses Volume voll wird.

df -h /var/lib/mongodb

Überprüfen Sie auch, welche Verzeichnisse wachsen:

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

Verwenden Sie Ihren tatsächlichen dbPath; /var/lib/mongodb ist bei Linux-Paketen üblich, aber nicht universell.

Überprüfen der MongoDB-Speichermetriken

Vergleichen Sie in mongosh die logische Datengröße mit der zugewiesenen Speichergröße.

use myDatabase
db.stats()

Nützliche Felder sind:

• dataSize: Logische Größe der Dokumentdaten.
• storageSize: Für Sammlungsdaten zugewiesener Speicherplatz.
• indexSize: Von Indizes belegter Speicherplatz.

Für eine bestimmte Sammlung:

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

Achten Sie auf size, storageSize und totalIndexSize. Wenn storageSize viel größer als size ist, hat die Sammlung möglicherweise wiederverwendbaren internen Speicherplatz durch Aktualisierungen und Löschungen. Wenn totalIndexSize groß ist, sind Indizes möglicherweise der schnellste Weg, um die Festplattennutzung zu reduzieren.

Häufige Ursachen für MongoDB-Festplattenwachstum

Hohe Lösch- und Aktualisierungsraten können internen freien Speicherplatz in WiredTiger-Dateien hinterlassen. MongoDB wird diesen Speicherplatz oft für zukünftige Schreibvorgänge wiederverwenden, aber das Betriebssystem zeigt die Dateien möglicherweise immer noch als groß an.

Indizes können ebenfalls einen großen Anteil der Festplatte belegen. Zusammengesetzte Indizes, Textindizes, Wildcard-Indizes und doppelte Indizes summieren sich schnell.

Aufbewahrungslücken sind eine weitere häufige Ursache. Protokoll-, Sitzungs-, Ereignis- und Audit-Sammlungen wachsen endlos, es sei denn, Sie archivieren oder verfallen alte Dokumente.

Sichere Möglichkeiten zur Reduzierung zukünftigen Wachstums

Die beste Festplattenlösung besteht normalerweise darin, unbegrenztes Wachstum zu verhindern.

Erstellen Sie für zeitbasierte Daten einen TTL-Index:

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

Die TTL-Löschung wird von einem Hintergrundmonitor durchgeführt und ist nicht sekundengenau. Sie ist dennoch gut geeignet für Protokolle, Sitzungen und temporäre Ereignisse, bei denen der genaue Löschzeitpunkt nicht kritisch ist.

Überprüfen Sie Indizes, bevor Sie etwas löschen:

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

$indexStats kann zeigen, ob ein Index seit dem Start des Prozesses verwendet wurde. Behandeln Sie dies als Hinweis, nicht als Beweis. Ein monatlicher Berichtsindex kann in einer ruhigen Woche ungenutzt erscheinen.

Löschen Sie einen bestätigten ungenutzten Index nach Namen:

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

Freigeben von Speicherplatz aus vorhandenen Dateien

Das Löschen von Dokumente schrumpft normalerweise keine WiredTiger-Dateien auf der Festplatte. Um Speicherplatz an das Dateisystem zurückzugeben, benötigen Sie eine Umschreibungs- oder Komprimierungsstrategie.

Verwenden Sie compact mit Vorsicht

compact kann Sammlungs- und Indexdaten umschreiben, um die Festplattennutzung zu reduzieren. Es ist ressourcenintensiv und kann je nach MongoDB-Version und Bereitstellung Operationen auf der betroffenen Sammlung blockieren.

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

Führen Sie es während eines Wartungsfensters aus, testen Sie es zuerst und lesen Sie die Dokumentation für Ihre genaue MongoDB-Version. In Replica Sets komprimieren viele Teams ein Secondary nach dem anderen, lassen es aufholen und wechseln dann die Rollen oder rotieren die Mitglieder nach Bedarf.

Dump und Wiederherstellung bei schwerer Fragmentierung

Bei stark fragmentierten Daten baut ein Dump-and-Restore die Sammlungsdateien sauber neu auf. Dies ist störend, wenn Sie es direkt durchführen, planen Sie daher Backups, Ausfallzeiten oder eine replikabasierte Migration.

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

Nachdem Sie den Dump überprüft und den Umstieg geplant haben, stellen Sie in der Zielumgebung wieder her:

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

Löschen Sie keine Produktionsdaten, bis Sie ein verifiziertes Backup und einen Rollback-Plan haben.

Was Sie nicht tun sollten

Löschen Sie keine WiredTiger-, Journal- oder Sammlungsdateien manuell aus dem Dateisystem. Dies kann die Datenbank beschädigen.

Gehen Sie nicht davon aus, dass du und die logische MongoDB-Größe übereinstimmen sollten. Komprimierung, Indizes, interner freier Speicherplatz und Dateisystemverhalten beeinflussen alle die Zahlen.

Seien Sie vorsichtig mit alten Ratschlägen zur MMAPv1-Vorzuweisung. Moderne MongoDB-Bereitstellungen verwenden typischerweise WiredTiger, und dessen Speicherverhalten ist anders.

Praktische Erkenntnisse

Wenn die MongoDB-Festplattennutzung falsch aussieht, messen Sie zuerst den Host, dann Datenbanken, Sammlungen und Indizes. Verwenden Sie TTL-Indizes und Archivierung, um das Wachstum zu verlangsamen. Löschen Sie nur bestätigte unnötige Indizes. Für eine echte Dateisystem-Rückgewinnung planen Sie compact oder einen Dump-and-Restore-Workflow, anstatt zu erwarten, dass Löschungen Dateien sofort schrumpfen.