Mongodb-Datendateien werden nach der Migration kleiner

Question

Auf meinem ersten Server bekomme ich:

root@prod ~ # du -hs /var/lib/mongodb/
909G    /var/lib/mongodb/

Nach der Migration Das Datenbank mit Mongodump/Mongorestore auf meinem zweiten Server, den ich bekomme:

root@prod ~ # du -hs /var/lib/mongodb/
30G /var/lib/mongodb/

Nachdem ich ein paar Stunden gewartet hatte, beendete Mongo die Indizierung und bekam:

root@prod ~ # du -hs /var/lib/mongodb/
54G /var/lib/mongodb/

Ich habe die Datenbank getestet und es gibt keine beschädigten oder fehlenden Daten.

Warum gibt es vor und nach der Migration so große Größenunterschiede?

Answer 1

MongoDB stellt keinen Speicherplatz wieder her, wenn die Datengröße aufgrund der Datenlöschung oder aus anderen Gründen tatsächlich sinkt.In den Online-Dokumenten gibt es eine gute Erklärung:

Warum sind die Dateien in meinem Datenverzeichnis größer als die Daten in meiner Datenbank?

Die Datendateien in Ihrem Datenverzeichnis, das das Verzeichnis /data /dB in Standardkonfigurationen ist, sind möglicherweise größer als der in die Datenbank eingefügte Datensatz.Berücksichtigen Sie die folgenden möglichen Ursachen:

Vorab zugewiesene Datendateien.

Im Datenverzeichnis prügt Mongodb Datendateien zu einer bestimmten Größe, teilweise zur Verhinderung von Dateisystemfragmentierung.MongoDB nennt die erste Datendatei .0, die nächste .1 usw.Die erste Datei -Mongod -Zuweisung beträgt 64 Megabyte, die nächsten 128 Megabyte usw. bis zu 2 Gigabyte, an diesem Punkt sind alle nachfolgenden Dateien 2 Gigabyte.Die Datendateien enthalten Dateien mit zugewiesenem Speicherplatz, die jedoch keine Daten enthalten.Mongod kann eine 1 Gigabyte -Datendatei zuweisen, die möglicherweise zu 90% leer ist.Für die meisten größeren Datenbanken ist der nicht verwendete zugewiesene Raum im Vergleich zur Datenbank gering.

Bei Unix-ähnlichen Systemen prealiert Mongod eine zusätzliche Datendatei und initialisiert den Speicherplatz auf 0.Die Vorab -Datendateien im Hintergrund verhindert erhebliche Verzögerungen, wenn als nächstes eine neue Datenbankdatei zugewiesen wird.

Sie können die Vorzuweisung deaktivieren, indem Sie preallocDataFiles auf „false“ setzen.Deaktivieren Sie preallocDataFiles jedoch nicht für Produktionsumgebungen:Verwenden Sie nur Preallocdatafiles zum Testen und mit kleinen Datensätzen, in denen Sie häufig Datenbanken fallen lassen.

Auf Linux -Systemen können Sie mit HDParm eine Vorstellung davon erhalten, wie kostspielig die Allokation sein kann:

Zeit hdparm --fallocate $((1024*1024)) Testdatei

Der Oplog.

Wenn dieser Mongod ein Mitglied eines Replikat -Sets ist, enthält das Datenverzeichnis die Datei oplog.rs, eine vorgebliebene Kollektion in der lokalen Datenbank.Die Standardzuweisung beträgt ungefähr 5% des Festplattenraums bei 64-Bit-Installationen. Weitere Informationen finden Sie unter OPLOG-Größen.In den meisten Fällen sollten Sie die Größe des Oplogs nicht ändern müssen.Wenn Sie dies jedoch tun, lesen Sie den Abschnitt „Ändern der Größe des Oplogs“.

Das Tagebuch.

Das Datenverzeichnis enthält die Journaldateien, die vor dem MongoDB Schreibvorgänge auf Festplatten speichern und sie auf Datenbanken anwenden.Siehe Journaling Mechanics.

Leere Datensätze.

MongoDB verwaltet beim Löschen von Dokumenten und Sammlungen Listen leerer Datensätze in Datendateien.MongoDB kann diesen Raum wiederverwenden, wird diesen Raum jedoch niemals an das Betriebssystem zurückgeben.

Verwenden Sie Kompakte, die den Raum defragmentiert haben, um den Speicherplatz zu defragmentieren.Durch die Entfaltung der Speicherung kann MongoDB den zugewiesenen Raum effektiv nutzen.Compact erfordert bis zu 2 Gigabyte zusätzlicher Festplattenraum, um zu laufen.Verwenden Sie nicht Compact, wenn Sie im Speicherplatz kritisch niedrig sind.

Wichtig

Compact entfernt die Fragmentierung nur aus MongoDB -Datendateien und gibt keinen Speicherplatz an das Betriebssystem zurück.

Verwenden Sie reparaturdatabase, die die Datenbank wieder aufbaut, um den Speicherplatz wieder aufzubauen, der den Speicher abfährt und Platz für das Betriebssystem abgibt.Reparaturdatabase erfordert bis zu 2 Gigabyte zusätzlichen Festplattenraum.Verwenden Sie keine Reparaturdatabase, wenn Sie auf dem Speicherplatz kritisch gering sind.

http://docs.mongodb.org/manual/faq/storage/

Was sie Ihnen nicht sagen, sind die beiden anderen Möglichkeiten, Speicherplatz wiederherzustellen/wiederherzustellen – mongodump/mongorestore wie Sie es getan haben oder das Hinzufügen eines neuen Mitglieds zum Replikatsatz mit einer leeren Festplatte, damit es seine Datenbankdateien von Grund auf neu schreibt.

Wenn Sie daran interessiert sind, dies zu überwachen, gibt der Befehl db.stats() eine Fülle von Daten zu Daten, Index, Speicher und Dateigrößen zurück:

http://docs.mongodb.org/manual/reference/command/dbStats/

Answer 2

Over time the MongoDB files develop fragmentation. When you do a "migration", or whack the data directory and force a re-sync, the files pack down. If your application does a lot of deletes or updates which grow the documents fragmentation develops fairly quickly. In our deployment it is updates that grow the documents that causes this. Somehow MongoDB moves the document when it sees that the updated document can't fit in the space of the original document. There is some way to add padding factors to the collection to avoid this.