Manage Journaling
On this page
MongoDB uses write ahead logging to an on-disk journal to guarantee write operation durability.
The WiredTiger storage engine does not require journaling to guarantee a consistent state after a crash. The database will be restored to the last consistent checkpoint during recovery. However, if MongoDB exits unexpectedly in between checkpoints, journaling is required to recover writes that occurred after the last checkpoint.
Note
Starting in MongoDB 4.0, you cannot specify --nojournal
option or storage.journal.enabled:
false
for replica set members that use the
WiredTiger storage engine.
With journaling enabled, if mongod
stops unexpectedly, the
program can recover everything written to the journal. MongoDB will
re-apply the write operations on restart and maintain a consistent
state. By default, the greatest extent of lost writes, i.e., those not
made to the journal, are those made in the last 100 milliseconds, plus
the time it takes to perform the actual journal writes. See
commitIntervalMs
for more information on
the default.
Procedures
Disable Journaling
Warning
Do not disable journaling on production systems.
Starting in MongoDB 4.0, you cannot specify
--nojournal
option orstorage.journal.enabled: false
for replica set members that use the WiredTiger storage engine.
To disable journaling for a standalone deployment, start
mongod
with the --nojournal
command line option.
Get Commit Acknowledgement
You can get commit acknowledgement with the Write Concern and
the j
option. For details, see
Write Concern.
Monitor Journal Status
The serverStatus
command/db.serverStatus()
method returns wiredTiger.log
, which contains
statistics on the journal.
Recover Data After Unexpected Shutdown
On a restart after a crash, MongoDB replays all journal files in the
journal directory before the server becomes available. If MongoDB must
replay journal files, mongod
notes these events in the log
output.
There is no reason to run --repair
.
Change WiredTiger Journal Compressor
With the WiredTiger storage engine, MongoDB, by default, uses the
snappy
compressor for the journal. To specify a different
compressions algorithm or no compression for a mongod
instance:
Tip
If you encounter an unclean shutdown for a mongod
during this procedure, you must use the old compressor settings to
recover using the journal files. Once recovered, you can retry the
procedure.