- 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. 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.
Without a journal, if mongod
exits unexpectedly, you must
assume your data is in an inconsistent state, and you must run either
repair
or, preferably, resync
from a clean member of the replica set.
With journaling enabled, if mongod
stops unexpectedly,
the program can recover everything written to the journal, and the
data remains in 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 journalCommitInterval
for more
information on the default.
With journaling, if you want a data set to reside entirely in RAM, you need enough RAM to hold the data set plus the “write working set.” The “write working set” is the amount of unique data you expect to see written between re-mappings of the private view. For information on views, see Storage Views used in Journaling.
Important
Procedures¶
Enable Journaling¶
Changed in version 2.0: For 64-bit builds of mongod
, journaling is enabled by default.
To enable journaling, start mongod
with the
--journal
command line option.
If no journal files exist, when mongod
starts, it must
preallocate new journal files. During this operation, the
mongod
is not listening for connections until preallocation
completes: for some systems this may take a several minutes. During
this period your applications and the mongo
shell are not
available.
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
getLastError
command and the j
option. For details, see
Write Concern Reference.
Avoid Preallocation Lag¶
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 commands and methods to monitor journal status:
-
The
serverStatus
command returns database status information that is useful for assessing performance. journalLatencyTest
Use
journalLatencyTest
to measure how long it takes on your volume to write to the disk in an append-only fashion. You can run this command on an idle system to get a baseline sync time for journaling. You can also run this command on a busy system to see the sync time on a busy system, which may be higher if the journal directory is on the same volume as the data files.The
journalLatencyTest
command also provides a way to check if your disk drive is buffering writes in its local cache. If the number is very low (i.e., less than 2 milliseconds) and the drive is non-SSD, the drive is probably buffering writes. In that case, enable cache write-through for the device in your operating system, unless you have a disk controller card with battery backed RAM.
Change the Group Commit Interval¶
Changed in version 2.0.
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.