Manage Journaling¶

On this page

Procedures

MongoDB uses write ahead logging to an on-disk journal to guarantee write operation durability and to provide crash resiliency.

With MMAPv1, before applying a change to the data files, MongoDB writes the change operation to the journal. If MongoDB should terminate or encounter an error before it can write the changes from the journal to the data files, MongoDB can re-apply the write operation 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. See commitIntervalMs for more information on the default.

With WiredTiger, even without journaling, checkpoints provide a consistent view of data on disk and allow MongoDB to recover from the last checkpoint. However, if MongoDB exits unexpectedly in between checkpoints, journaling is required to recover information that occured after the last checkpoint.

Procedures¶

Enable Journaling¶

For 64-bit builds of mongod, journaling is enabled by default.

To enable journaling, start mongod with the --journal command line option.

Disable Journaling¶

Warning

Do not disable journaling on production systems. If your mongod instance stops without shutting down cleanly unexpectedly for any reason, (e.g. power failure) and you are not running with journaling, then you must recover from an unaffected replica set member or backup, as described in repair.

To disable journaling, start mongod with the --nojournal command line option.

Get Commit Acknowledgment¶

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

Avoid Preallocation Lag for MMAPv1¶

With the MMAPv1 storage engine, MongoDB may preallocate journal files if the mongod process determines that it is more efficient to preallocate journal files than create new journal files as needed.

Depending on your filesystem, you might experience a preallocation lag the first time you start a mongod instance with journaling enabled. The amount of time required to pre-allocate files might last several minutes; during this time, you will not be able to connect to the database. This is a one-time preallocation and does not occur with future invocations.

To avoid preallocation lag, you can preallocate files in the journal directory by copying them from another instance of mongod.

Preallocated files do not contain data. It is safe to later remove them. But if you restart mongod with journaling, mongod will create them again.

Example

The following sequence preallocates journal files for an instance of mongod running on port 27017 with a database path of /data/db.

For demonstration purposes, the sequence starts by creating a set of journal files in the usual way.

Create a temporary directory into which to create a set of journal files:
copy
```
mkdir ~/tmpDbpath
```
Create a set of journal files by staring a mongod instance that uses the temporary directory:
copy
```
mongod --port 10000 --dbpath ~/tmpDbpath --journal
```
When you see the following log output, indicating mongod has the files, press CONTROL+C to stop the mongod instance:
copy
```
[initandlisten] waiting for connections on port 10000
```
Preallocate journal files for the new instance of mongod by moving the journal files from the data directory of the existing instance to the data directory of the new instance:
copy
```
mv ~/tmpDbpath/journal /data/db/
```

Start the new mongod instance:

copy

mongod --port 27017 --dbpath /data/db --journal

Monitor Journal Status¶

Use the following command to monitor journal status:

serverStatus

The serverStatus command returns database status information that is useful for assessing performance.

Change the Group Commit Interval for MMAPv1¶

For the MMAPv1 storage engine, you can set the group commit interval using the --journalCommitInterval command line option. The allowed range is 2 to 300 milliseconds.

Lower values increase the durability of the journal at the expense of disk performance.

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 repairDatabase in these situations.

← Rotate Log Files Store a JavaScript Function on the Server →