Docs Menu
Docs Home
MongoDB Manual
/ /

Manage Journaling

On this page

  • Procedures

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.

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.

You can get commit acknowledgment with the Write Concern and the j option. For details, see Write Concern.

The serverStatus command/db.serverStatus() method returns wiredTiger.log, which contains statistics on the journal.

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.

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:


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.

← Journaling
GridFS →

On this page