- Storage >
- Journaling >
- Manage Journaling
Manage Journaling¶
On this page
MongoDB uses write ahead logging to an on-disk journal to guarantee write operation durability. The MMAPv1 storage engine also requires the journal in order to provide crash resiliency.
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. - When using the MMAPv1 storage engine without a journal, 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 Acknowledgement¶
You can get commit acknowledgement with the Write Concern and
the j
option. For details, see
Write Concern.
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 starting a
mongod
instance that uses the temporary directory. For example:Tip
When possible, use a logical DNS hostname instead of an ip address, particularly when configuring replica set members or sharded cluster members. The use of logical DNS hostnames avoids configuration changes due to ip address changes.
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
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. For example:Tip
When possible, use a logical DNS hostname instead of an ip address, particularly when configuring replica set members or sharded cluster members. The use of logical DNS hostnames avoids configuration changes due to ip address changes.
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
Monitor Journal Status¶
The serverStatus
command/db.serverStatus()
method returns wiredTiger.log
, which contains
statistics on the WiredTiger journal.
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.
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.
- Standalone
- Replica Set Member
- Sharded Cluster Member
Use the following procedure to change the journal compressor
for a standalone mongod
instance:
Update the
storage.wiredTiger.engineConfig.journalCompressor
setting to the new value.If you use command-line options instead of a configuration file, you will have to update the
--wiredTigerJournalCompressor
command-line option during the restart below.Perform a clean shutdown of the
mongod
instance. For example, connect amongo
shell to the instance and issuedb.shutdownServer()
:Once you have confirmed that the process is no longer running, restart the
mongod
instance:If you are using a configuration file:
If you are using command-line options instead of a configuration file, update the
--wiredTigerJournalCompressor
option.
Use the following procedure to change the journal compressor for a member of a replica set:
Note
The following procedure involves restarting the replica member as a standalone without the journal.
Perform a clean shutdown of the
mongod
instance. For example, connect amongo
shell to the instance and issuedb.shutdownServer()
:Update the configuration file to prepare to restart as a standalone:
- Set
storage.journal.enabled
tofalse
. - Comment out the replication settings for your deployment.
- Set parameter
disableLogicalSessionCacheRefresh
totrue
in thesetParameter
section.
For example:
If you use command-line options instead of a configuration file, you will have to update the command-line option during the restart.
- Set
Restart the
mongod
instance:If you are using a configuration file:
If you are using command-line options instead of a configuration file,
Include the
--nojournal
optionRemove any replication command-line options (such as
--replSet
):Set parameter
disableLogicalSessionCacheRefresh
totrue
in the--setParameter
option.
Perform a clean shutdown of the
mongod
instance:Confirm that the process is no longer running.
Update the configuration file to prepare to restart as a replica set member with the new journal compressor:
- Remove the
storage.journal.enabled
setting. - Uncomment the replication settings for your deployment.
- Remove the
disableLogicalSessionCacheRefresh
parameter. - Remove
storage.wiredTiger.engineConfig.journalCompressor
setting to use the default journal compressor or specify a new value.
For example:
If you use command-line options instead of a configuration file, you will have to update the command-line options during the restart below.
- Remove the
Restart the
mongod
instance as a replica set member:If you are using a configuration file:
If you are using command-line options instead of a configuration file:
- Remove the
--nojournal
option. - Remove the
--wiredTigerJournalCompressor
command-line option to use the default journal compressor or update to a new value. - Include your replication command-line options as well as any additional options for your replica set member.
- Remove the
disableLogicalSessionCacheRefresh
parameter.
- Remove the
Use the following procedure to change the journal compressor for a member of a shard replica set or config server replica set:
Note
The following procedure involves restarting the replica member as a standalone without the journal.
Perform a clean shutdown of the
mongod
instance. For example, connect amongo
shell to the instance and issuedb.shutdownServer()
:Update the configuration file to prepare to restart as a standalone:
- Set
storage.journal.enabled
tofalse
. - Set parameter
skipShardingConfigurationChecks
to true. - Set parameter
disableLogicalSessionCacheRefresh
totrue
in thesetParameter
section. - Comment out the replication settings for your deployment.
- Comment out the
sharding.clusterRole
setting. - Set the
net.port
to the member’s current port, if it is not explicitly set.
For example:
If you use command-line options instead of a configuration file, you will have to update the command-line option during the restart.
- Set
Restart the
mongod
instance:If you are using a configuration file:
If you are using command-line options instead of a configuration file:
- Include the
--nojournal
option. - Set parameter
skipShardingConfigurationChecks
to true. - Set parameter
disableLogicalSessionCacheRefresh
totrue
in the--setParameter
option. - Remove any replication command-line options (such as
--replSet
). - Remove
--shardsvr
/--configsvr
option. - Explicitly include
--port
set to the instance’s current port.
- Include the
Perform a clean shutdown of the
mongod
instance:Confirm that the process is no longer running.
Update the configuration file to prepare to restart with the new journal compressor:
- Remove the
storage.journal.enabled
setting. - Remove the
skipShardingConfigurationChecks
parameter setting. - Remove the
disableLogicalSessionCacheRefresh
parameter setting. - Uncomment the replication settings for your deployment.
- Uncomment the
sharding.clusterRole
setting. - Remove
storage.wiredTiger.engineConfig.journalCompressor
setting to use the default journal compressor or specify a new value.
For example:
If you use command-line options instead of a configuration file, you will have to update the command-line options during the restart below.
- Remove the
Restart the
mongod
instance as a replica set member:If you are using a configuration file:
If you are using command-line options instead of a configuration file:
- Remove the
--nojournal
option. - Remove the
skipShardingConfigurationChecks
parameter setting. - Remove the
disableLogicalSessionCacheRefresh
parameter. - Remove the
--wiredTigerJournalCompressor
command-line option to use the default journal compressor or update to a new value. - Include
--shardsvr
/--configsvr
option. - Include your replication command-line options as well as any additional options for your replica set member.
- Remove the