Journaling in MongoDB verwalten

MongoDB kann wie jede andere Datenbank beim Ausführen eines Schreibvorgangs fehlschlagen. In diesem Fall brauchen wir eine Strategie, die den Betrieb irgendwo hält, damit die Datenbank wieder aufgenommen werden kann, wenn sie wieder in Betrieb ist.

In MongoDB verwenden wir Journaling, wobei es eine Write-Ahead-Protokollierung in Journaldateien auf der Festplatte gibt, um die Daten im Falle eines Fehlers verfügbar zu halten. Die WiredTiger-Speicher-Engine kann Checkpoints verwenden, um eine konsistente Ansicht der Daten auf der Festplatte bereitzustellen und MongoDB die Wiederherstellung vom letzten Checkpoint zu ermöglichen, aber nur, wenn es nicht unerwartet beendet wurde. Andernfalls muss für die Informationen, die während des letzten Prüfpunkts aufgetreten sind, Journaling aktiviert worden sein, um solche Daten wiederherzustellen.

Das Verfahren für den Wiederherstellungsprozess ist wie folgt:Die Datenbank sucht in den Datendateien nach der Kennung des letzten Prüfpunkts, verwendet diese Kennung, um in den Journaldateien nach dem passenden Datensatz zu suchen und Wenden Sie dann die Operationen in den Journaldateien seit dem letzten Prüfpunkt an.

Wie Journaling in der WiredTiger-Speicher-Engine funktioniert

Für jeden Client, der einen Schreibvorgang initiiert, erstellt WiredTiger einen Journaleintrag, der sich aus internen Schreibvorgängen zusammensetzt, die durch den ersten Schreibvorgang ausgelöst wurden. Stellen Sie sich ein Dokument in einer Sammlung vor, das aktualisiert werden soll, und wir erwarten, dass auch sein Index geändert wird. Der WiredTiger erstellt einen einzelnen Journaleintrag, der den Aktualisierungsvorgang und die entsprechenden Indexänderungen enthält.

Dieser Datensatz wird in einem In-Memory-Puffer gespeichert, dessen maximale Kapazität 128 KB beträgt. Die Speicher-Engine synchronisiert dann diese gepufferten Journaleinträge auf die Festplatte, wenn eine der folgenden Bedingungen erfüllt ist:

Eine Schreiboperation beinhaltet/impliziert ein Schreibproblem von j:true.
WiredTiger erstellt eine neue Journaldatei, die alle 100 MB Daten enthält.
Nach jeweils 100 Millisekunden, abhängig von storage.journal.commitIntervalMs.
Im Fall von Replica-Set-Mitgliedern:
- Instanz von Vorgängen, die auf Oplog-Einträge warten, d. h. Lesevorgänge, die als Teil von kausal konsistenten Sitzungen ausgeführt werden , und Vorwärtsscannen von Abfragen für das Oplog.
- Nach jeder Stapelanwendung der Oplog-Einträge im Fall der sekundären Mitglieder.

Im Falle eines harten Herunterfahrens von mongod können Aktualisierungen verloren gehen, wenn Schreibvorgänge ausgeführt wurden, selbst wenn die Journalaufzeichnungen in den WiredTiger-Puffern verbleiben.

Journaldatenkomprimierung

Die Standardeinstellung in MongoDB weist den WiredTiger an, eine schnelle Komprimierung für die Journaldaten zu verwenden. Dies kann je nach gewünschtem Komprimierungsalgorithmus mithilfe der Einstellung storage.wiredTiger.engineConfig.journalCompressor geändert werden. Diese Protokolldatensätze werden nur komprimiert, wenn ihre Größe größer als 128 Byte ist, was die minimale Größe der Protokolldatensätze von WiredTiger ist.

Die Größe einer Journaldatei begrenzen

Die maximale Größe einer Journaldatei beträgt 100 MB. Wenn die Datei diese Grenze überschreitet, wird daher eine neue erstellt.

Nachdem die Journaldatei bei der Wiederherstellung verwendet wurde bzw. Dateien vorhanden sind, die älter sind als die, die zur Wiederherstellung vom letzten Prüfpunkt verwendet werden können, entfernt der WiredTiger diese automatisch.

Vorabzuweisung

Journaldateien können mit der WiredTiger-Speicher-Engine vorab zugewiesen werden, wenn der Mongod-Prozess feststellt, dass es effizienter ist, Journaldateien vorab zuzuweisen als neue zu erstellen.

Wie Journaling in der In-Memory-Speicher-Engine funktioniert

Die In-Memory-Speicher-Engine wurde als Teil der allgemeinen Verfügbarkeit (GA) ab Version 3.2.6 von MongoDB Enterprise angegeben. Bei dieser Speicher-Engine werden Daten im Speicher gehalten, daher keine separate Journaling-Technik. Wenn es Schreiboperationen mit einem Write Concern (j:true) gibt, werden diese sofort bestätigt.

Für einen Replikatsatz mit einem stimmberechtigten Mitglied , das die In-Memory-Speicher-Engine verwendet, muss "writeConcernMajorityJournalDefault" auf "false" gesetzt werden. Andernfalls, wenn dies auf "true" gesetzt ist, protokolliert der Replikatsatz eine Startwarnung.

Wenn diese Option auf „false“ gesetzt ist, wartet die Datenbank nicht darauf, dass w:„majority“-Schreibvorgänge in das On-Disk-Journal geschrieben werden, bevor die Schreibvorgänge bestätigt werden. Der Nachteil dieses Ansatzes besteht darin, dass bei Mehrheitsschreibvorgängen im Falle eines vorübergehenden Verlusts (z. B. Neustart oder Absturz) einer Mehrheit von Knoten in einem bestimmten Replikatsatz ein Rollback ausgeführt werden kann.

Wenn Sie die MMapv1-Speicher-Engine verwenden, kann die Journal-Vorabzuweisung mit der Option --nopreallocation beim Starten von Mongod deaktiviert werden.

Mit der WiredTiger-Speicher-Engine ab MongoDB-Version 4.0 ist es nicht möglich, die Option --nojournal oder sogar die storage.journal.enabled:false für Replica-Set-Mitglieder anzugeben, die die WiredTiger-Speicher-Engine verwenden.

Journal verwalten

Journaling deaktivieren

Journaling kann nur für eigenständige Bereitstellungen deaktiviert werden und wird für Produktionssysteme nicht empfohlen. Ab MongoDB-Version 4.0 kann weder die Option --nojournal noch storage.journal.enabled:false angegeben werden, wenn Replica-Set-Mitglieder beteiligt sind, die die WiredTiger-Speicher-Engine verwenden.

Um das Journaling zu deaktivieren, starten Sie Mongod mit der Befehlszeilenoption --nojournal.

Journalstatus überwachen

Um die Statistik des Journals zu erhalten, verwenden Sie den Befehl db.serverStatus(), der wiredTiger.log zurückgibt.

Commit-Bestätigung erhalten

Wir verwenden die Option Write Concern with j, um eine Commit-Bestätigung zu erhalten. {j:wahr}. Journaling muss in diesem Fall aktiviert werden, sonst kann die Mongod-Instanz einen Fehler erzeugen.

Wenn Journaling aktiviert ist, kann w:„Mehrheit“ bedeuten, dass j:wahr ist.

Für einen Replikatsatz erfordert das Setup, wenn j:true ist, dass nur der primäre in das Journal schreibt, unabhängig von der w: write-Betroffenheit.

Aber selbst wenn j:true für einen Replikatsatz konfiguriert ist, können Rollbacks aufgrund eines primären Failovers des Replikatsatzes auftreten.

Datenwiederherstellung nach unerwartetem Herunterfahren

Alle Journaldateien im Journalverzeichnis werden immer dann wiedergegeben, wenn MongoDB nach einem Absturz neu gestartet wird, bevor der Server erkannt wird. Da dieser Vorgang in der Protokollausgabe aufgezeichnet wird, besteht keine Notwendigkeit, --repair.

auszuführen

Änderung des WiredTiger-Journalkompressors

Snappy Compressor ist der standardmäßige Komprimierungsalgorithmus für das Journal. Allerdings kann man dies je nach Einrichtung der Mongod-Instanz ändern.

Für eine eigenständige Mongod-Instanz:

Setzen Sie den storage.wiredTiger.engineConfig.journalCompressor auf einen neuen Wert, um ihn zu aktualisieren. Der geeignetste Weg, dies zu tun, ist über die Konfigurationsdatei, aber wenn Sie die Befehlszeilenoptionen verwenden, müssen Sie die Befehlszeilenoption --wiredTigerJournalCompressor während des Neustarts aktualisieren.
Fahren Sie die Mongod-Instanz herunter, indem Sie eine Verbindung zu einer Mongo-Shell der Instanz herstellen und den Befehl ausgeben:db.shutdownServer() oder db.getSiblingDB('admin ).shutdownServer()
Starten Sie die Mongod-Instanz neu:
1. Wenn Sie die Konfigurationsdatei verwenden, verwenden Sie:mongod -f
2. Wenn Sie Befehlszeilenoptionen verwenden, aktualisieren Sie den wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Für ein Replikat-Set-Mitglied:

Fahren Sie die Mongod-Instanz herunter:db.shutdownServer() oder db.getSiblingDB(‘admin).shutdownServer()
Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei vor:
1. Setze storage.journal.enabled auf false.
2. Kommentieren Sie die Replikationseinstellungen
3. Setzen Sie den Parameter disableLogicalSessionCacheRefresh auf true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Starte die Mongod-Instanz neu:
1. Wenn Sie die Konfigurationsdatei verwenden, verwenden Sie:mongod -f
2. Bei Verwendung der Befehlszeilenoptionen:Schließen Sie die Option --nojournal ein, entfernen Sie alle Befehlszeilenoptionen für die Replikation d. h. --replSet und setze den Parameter disableLogicalSessionCacheRefresh auf true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Mongod-Instanz herunterfahren:

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

Aktualisieren Sie die Konfigurationsdatei, um einen Neustart des Replikatgruppenmitglieds mit dem neuen Journalkompressor vorzubereiten:Entfernen Sie den Speicher. journal.enabled, kommentieren Sie die Replikationseinstellungen für die Bereitstellung aus, entfernen Sie die Option disableLogicalSessionCacheRefresh und entfernen Sie schließlich storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Starten Sie die Mongod-Instanz als Replikat-Set-Mitglied neu

Wenn Sie die Konfigurationsdatei verwenden, verwenden Sie:mongod -f
Bei Verwendung der Befehlszeilenoptionen:Entfernen Sie die Optionen --nojournal und --wiredTigerJournalCompressor. Schließen Sie die Befehlszeilenoptionen für die Replikation ein und entfernen Sie den Parameter disableLogicalSessionCacheRefresh.

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Fazit

Damit MongoDB eine Dauerhaftigkeit des Schreibvorgangs garantiert, wird Journaling verwendet, wobei Daten im Voraus auf die Festplatte geschrieben werden Protokollierung. So sehr die WiredTiger-Speicher-Engine (die am meisten bevorzugt wird) Daten über die letzten Checkpoints wiederherstellen kann, wenn MongoDB unerwartet beendet wird und das Journaling nicht aktiviert wurde, wird die Wiederherstellung solcher Daten unmöglich. Andernfalls kann MongoDB bei aktiviertem Journaling die Schreibvorgänge beim Neustart erneut anwenden und einen konsistenten Zustand beibehalten.