On this page本页内容
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.
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.
Warning
Do not disable journaling on production systems.
--nojournal
option or storage.journal.enabled:
false
for replica set members that use the WiredTiger storage engine.To disable journaling for a standalone deployment, start mongod
with the --nojournal
command line option.
You can get commit acknowledgement 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:
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.
Use the following procedure to change the journal compressor for a standalone mongod
instance:
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.
mongod
instance. For example, connect a mongo
shell to the instance and issue db.shutdownServer()
:
mongod
instance:
--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.
mongod
instance. For example, connect a mongo
shell to the instance and issue db.shutdownServer()
:
storage.journal.enabled
to false
.disableLogicalSessionCacheRefresh
to true
in the setParameter
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.
mongod
instance:
--nojournal
option--replSet
):disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.
mongod
instance:
Confirm that the process is no longer running.
storage.journal.enabled
setting.disableLogicalSessionCacheRefresh
parameter.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.
mongod
instance as a replica set member:
--nojournal
option.--wiredTigerJournalCompressor
command-line option to use the default journal compressor or update to a new value.disableLogicalSessionCacheRefresh
parameter.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.
mongod
instance. For example, connect a mongo
shell to the instance and issue db.shutdownServer()
:
storage.journal.enabled
to false
.skipShardingConfigurationChecks
to true.disableLogicalSessionCacheRefresh
to true
in the setParameter
section.sharding.clusterRole
setting.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.
mongod
instance:
--nojournal
option.skipShardingConfigurationChecks
to true.disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.--replSet
).--shardsvr
/--configsvr
option.--port
set to the instance’s current port.mongod
instance:
Confirm that the process is no longer running.
storage.journal.enabled
setting.skipShardingConfigurationChecks
parameter setting.disableLogicalSessionCacheRefresh
parameter setting.sharding.clusterRole
setting.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.
mongod
instance as a replica set member:
--nojournal
option.skipShardingConfigurationChecks
parameter setting.disableLogicalSessionCacheRefresh
parameter.--wiredTigerJournalCompressor
command-line option to use the default journal compressor or update to a new value.--shardsvr
/--configsvr
option.