Wie funktioniert MongoDB Journaling Arbeit

Question

Hier ist meine Ansicht, und ich bin nicht sicher, ob es richtig oder falsch ist:

Das Journaling-Protokoll ist das „Wiederholen“ log. Es zeichnet die Änderung der Datendateien auf.

Zum Beispiel möchte ich den Feldwert eines Datensatzes von 'a' in 'b' ändern, dann wird der mongodb finden, wie man die dbfile ändert (alle Namespaces, Daten, Indizes und so weiter), dann schreibt mongodb die Änderungen in das Journal.

Danach macht mongodb alle echten Änderungen an der dbfile. Wenn hier etwas schief geht, wenn mongoDB neu startet, liest es das Journal (falls es existiert). Es ändert dann die alter dbfile, um den Datensatz konsistent zu machen.

So im Journal werden die zu ändernden Daten nicht aufgezeichnet, sondern stattdessen, wie Sie die dbfile ändern.

Bin ich richtig? Wo kann ich mehr Informationen über das Format der Zeitschrift erhalten?

Answer 1

EDIT: mein ursprünglicher Link zu einer 2011 Präsentation bei MongosF von Dwight ist jetzt tot, aber es gibt eine 2012 presentation von Ben Becker mit ähnlichen Inhalten.

Nur für den Fall, dass die Arbeit zu irgendeinem Zeitpunkt zu stoppen, werde ich eine kurze Zusammenfassung der Funktionsweise der Zeitschrift in der ursprünglichen MMAP Speicher-Engine geben, aber es sollte darauf hingewiesen, dass mit dem Aufkommen der pluggable storage engine-Modell (MongoDB 3.0 und später), hängt dies nun vollständig von der Speicher-Engine (und möglicherweise den Optionen) ab, die Sie verwenden - überprüfen Sie das bitte.

Zurück zum ursprünglichen (MMAP) Speichermodul Journal. Auf einer sehr rudimentären Ebene enthält das Journal eine Reihe von in die Warteschlange eingereihten Operationen, und alle Operationen werden in diese geschrieben, wenn sie passieren - im Grunde genommen nur ein sequentielles Schreiben auf Platte.

Sobald diese Operationen angewendet und auf die Festplatte übertragen wurden, werden sie im Journal nicht mehr benötigt und können ausgemagert werden. In diesem Sinne wirkt das Journal grundsätzlich wie ein Ringpuffer für Schreiboperationen.

Intern werden die Vorgänge im Journal in "commit groups" gespeichert - eine logische Gruppe von Schreibvorgängen. Sobald sich eine Operation in einer vollständigen Festschreibungsgruppe befindet, kann sie als Teil des Journals mit der Platte synchronisiert werden (und erfüllt beispielsweise die Schreibanforderungen von j:true). Nach einem unsauberen Herunterfahren versucht mongod, alle vollständigen Commit-Gruppen anzuwenden, die zuvor nicht auf die Festplatte geleert wurden, unvollständige Commit-Gruppen werden verworfen.

Die Vorgänge im Journal sind nicht das, was Sie in der oplog sehen werden, sondern sie sind eine einfachere Reihe von Dateien, Offsets (im Wesentlichen Festplattenplätze) und Daten an der Stelle geschrieben werden. Dies ermöglicht eine effiziente Wiedergabe der Daten und ein kompaktes Format für das Journal, lässt aber die Inhalte für die meisten wie Kauderwelsch aussehen (im Gegensatz zu dem zuvor erwähnten oplog, das grundsätzlich als JSON-Dokumente lesbar ist). Dies beantwortet im Wesentlichen eine der gestellten Fragen - es hat keine Kenntnis vom Inhalt der Datenbankdatei und den daran zu machenden Änderungen, es ist noch einfacher - es weiß im Grunde nur, zum Plattenplatz X zu gehen und Daten Y zu schreiben, das ist es.

Die sequenzielle Schreibweise des Journals bedeutet, dass es gut auf eine sich drehende Festplatte passt und das sequenzielle Zugriffsmuster in der Regel nicht mit den MMAP-Datenzugriffsmustern übereinstimmt (jedoch nicht notwendigerweise mit den Zugriffsmustern anderer Engines). . Daher ist es manchmal eine gute Idee, das Journal auf eine eigene Festplatte oder Partition zu legen, um IO-Konflikte zu reduzieren.