Freier Speicherplatz von MongoDB 3.2 wiederherstellen

Hintergrund: MongoDB ReplicaSet mit 1 Mitglied und 1 Arbiter ist eingerichtet. Es ist notwendig, Speicherplatz freizugeben, da Daten in MongoDB nicht mehr benötigt werden. Alle Dokumente wurden mit db.collection.remove({}) Befehl entfernt. Nach db.runCommand ({ compact: 'collection', force:true}), db.collection.reIndex() und db.repairDatabase() liefen wurden, sahen db.stats() wie:Freier Speicherplatz von MongoDB 3.2 wiederherstellen

> db.stats() 
{ 
    "db" : "database", 
    "collections" : 2, 
    "objects" : 6, 
    "avgObjSize" : 167.83333333333334, 
    "dataSize" : 1007, 
    "storageSize" : 153042944, 
    "numExtents" : 0, 
    "indexes" : 5, 
    "indexSize" : 45056, 
    "ok" : 1 
}

Wie Sie sehen können, gibt es nur 6 Dokumente in DB (in den zweiten Sammlungen) mit einem Gesamtspeichergröße von 153MB. Aber , wenn wir an der Speicherplatznutzung aussehen:

# du -h --max-depth=1 | grep mongodb 
9.8G ./mongodb

Und innen mongodb Verzeichnis:

ls -l 
total 9365696 
-rw-r----- 1 username usergroup  16384 Aug 19 14:19 collection-0-2472884588219438804.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:19 collection-0-4266045208498277842.wt 
-rw-r----- 1 username usergroup  12288 Aug 24 15:55 collection-0--7009505821458556818.wt 
-rw-r----- 1 username usergroup  49152 Aug 19 14:20 collection-0--7439052959034576211.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:20 collection-0-8676027872146699793.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:19 collection-2-2472884588219438804.wt 
-rw-r----- 1 username usergroup  32768 Aug 23 13:54 collection-2-2911328926458913167.wt 
-rw-r----- 1 username usergroup 9589645312 Aug 24 15:55 collection-4-2472884588219438804.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:19 collection-7--7439052959034576211.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:19 collection-9--7439052959034576211.wt 
drwxr-x--- 2 username usergroup  4096 Aug 24 16:03 diagnostic.data 
-rw-r----- 1 username usergroup  4096 Aug 24 15:54 index-10-561247476684508201.wt 
-rw-r----- 1 username usergroup  36864 Jul 20 15:09 index-10--7439052959034576211.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:19 index-11--7439052959034576211.wt 
-rw-r----- 1 username usergroup  16384 Mar 4 09:20 index-1-2472884588219438804.wt 
-rw-r----- 1 username usergroup  36864 Jul 20 15:09 index-1-4266045208498277842.wt 
-rw-r----- 1 username usergroup  36864 Aug 19 14:20 index-1--7439052959034576211.wt 
-rw-r----- 1 username usergroup  16384 Jul 5 13:25 index-1-8676027872146699793.wt 
-rw-r----- 1 username usergroup  36864 Jul 20 15:09 index-2-4266045208498277842.wt 
-rw-r----- 1 username usergroup  16384 Mar 4 09:20 index-3-2472884588219438804.wt 
-rw-r----- 1 username usergroup  16384 Aug 23 14:00 index-6-561247476684508201.wt 
-rw-r----- 1 username usergroup  16384 Aug 23 14:00 index-7-561247476684508201.wt 
-rw-r----- 1 username usergroup  4096 Aug 24 15:54 index-8-561247476684508201.wt 
-rw-r----- 1 username usergroup  16384 Aug 19 14:19 index-8--7439052959034576211.wt 
-rw-r----- 1 username usergroup  4096 Aug 24 15:54 index-9-561247476684508201.wt 
drwxr-x--- 2 username usergroup  4096 Aug 24 15:55 journal 
-rw-r----- 1 username usergroup  36864 Aug 24 15:55 _mdb_catalog.wt 
-rwxr-x--- 1 username usergroup   6 Aug 19 14:19 mongod.lock 
-rw-r----- 1 username usergroup  36864 Aug 24 15:56 sizeStorer.wt 
-rw-r----- 1 username usergroup   95 Dec 30 2015 storage.bson 
-rw-r----- 1 username usergroup   46 Dec 30 2015 WiredTiger 
-rw-r----- 1 username usergroup  534 Dec 30 2015 WiredTiger.basecfg 
-rw-r----- 1 username usergroup  4096 Aug 19 14:19 WiredTigerLAS.wt 
-rw-r----- 1 username usergroup   21 Dec 30 2015 WiredTiger.lock 
-rw-r----- 1 username usergroup  903 Aug 24 15:57 WiredTiger.turtle 
-rw-r----- 1 username usergroup  94208 Aug 24 15:57 WiredTiger.wt

Diese Saite scheint mir seltsam:

-rw-r----- 1 username usergroup 9589645312 Aug 24 15:55 collection-4-2472884588219438804.wt

Frage: Was kann in Mystery Sammlung-4-2472884588219438804.wt Datei sein? Warum wird es nicht von kompakten repairDatabase-Befehlen beeinflusst? Gibt es eine Möglichkeit, MongoDB zu erzwingen, diese Datei leer zu lassen oder ihren Speicherplatz zurückzugewinnen?

Update: Mit Hilfe von @ James-Wahlin haben wir herausgefunden, dass 9.8Gb ist die Replica Set Oplog Größe. Aber wie kann ich MongoDB zwingen, Platz zu schaffen, trotz möglichem Datenverlust für andere Replikat-Set-Mitglieder?

Quelle

2016-08-24 cleversokol

Meine Vermutung ist, dass dies die local.oplog.rs Sammlung ist (https://docs.mongodb.com/manual/core/replica-set-oplog/). Sehen Sie sich db stats in der 'lokalen' Datenbank an, um zu bestätigen. –

Ja, Sie hatten absolut Recht! Es ist oplog.rs die file: '> db.oplog.rs.stats() { "ns": "local.oplog.rs", "count": 30.036.627, "Größe": 7106989772, "avgObjSize" : 236, "storageSize": 9589645312, "capped": true, "max": -1, "maxSize": NumberLong ("7050707456"), "sleepCount": 0, "sleepMS": 0 , "wiredTiger": { ..., "uri": "Statistik: Tabelle: collection-4-2472884588219438804", ' – cleversokol

@JamesWahlin, kann ich irgendwie MongoDB zwingen, diese Sammlungen zu bereinigen, oder es leer? Ich weiß, dass keine Mitglieder synchronisiert werden müssen und diese Daten werden nicht mehr benötigt. Ich habe immer eine Option, mit der leeren DB auf dem zweiten Mitgliedsknoten zu synchronisieren, wenn ich möchte. – cleversokol

Aufgrund der Tatsache, Sie alle Dokumente entfernt, und die Daten nicht mehr benötigt wird: manuell

> use admin 
switched to db admin 
> db.shutdownServer() 
2016-08-24T08:50:29.085-0500 I NETWORK DBClientCursor::init call() failed server should be down... 
2016-08-24T08:50:29.096-0500 I NETWORK trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed 
2016-08-24T08:50:30.103-0500 W NETWORK Failed to connect to 127.0.0.1:27017, reason: errno:10061 No connection could be made because the target machine actively refused it. 
2016-08-24T08:50:30.104-0500 I NETWORK reconnect 127.0.0.1:27017 (127.0.0.1) failed failed couldn't connect to server 127.0.0.1:27017 (127.0.0.1), connection attempt failed 
> 

# cd ./mongodb 
# rm -rf *

Stoppen Sie den mongod Prozess
alle Dateien aus dem Verzeichnis entfernen ./mongodb

Wenn Sie Mongo neu starten, wird das Verzeichnis mongodb nach Bedarf initialisiert.

Quelle

2016-08-24 13:55:29 tawman

Freier Speicherplatz von MongoDB 3.2 wiederherstellen

Antwort

Verwandte Themen