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.