- Administration >
- Administration Tutorials >
- Configuration, Maintenance, and Analysis >
- Manage Journaling
Manage Journaling¶
On this page
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:
Create a set of journal files by staring a
mongod
instance that uses the temporary directory:When you see the following log output, indicating
mongod
has the files, press CONTROL+C to stop themongod
instance: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:Start the new
mongod
instance:
Monitor Journal Status¶
Use the following command to monitor journal status:
-
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.