Manage Journaling

MongoDB uses write ahead logging to an on-disk journal toguarantee write operation durability.

The WiredTiger storage engine does not require journaling to guaranteea consistent state after a crash. The database will be restored to thelast consistent checkpointduring recovery. However, if MongoDB exits unexpectedly in betweencheckpoints, journaling is required to recover writes that occurredafter 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 theWiredTiger storage engine.

With journaling enabled, if mongod stops unexpectedly, theprogram can recover everything written to the journal. MongoDB willre-apply the write operations on restart and maintain a consistentstate. By default, the greatest extent of lost writes, i.e., those notmade to the journal, are those made in the last 100 milliseconds, plusthe time it takes to perform the actual journal writes. SeecommitIntervalMs for more information onthe default.

Procedures

Disable Journaling

Warning

Do not disable journaling on production systems.

To disable journaling for a standalone deployment, startmongod with the —nojournal command line option.

Get Commit Acknowledgement

You can get commit acknowledgement with the Write Concern andthe j option. For details, seeWrite Concern.

Monitor Journal Status

The serverStatus command/db.serverStatus()method returns wiredTiger.log, which containsstatistics on the journal.

Recover Data After Unexpected Shutdown

On a restart after a crash, MongoDB replays all journal files in thejournal directory before the server becomes available. If MongoDB mustreplay journal files, mongod notes these events in the logoutput.

There is no reason to run —repair.

Change WiredTiger Journal Compressor

With the WiredTiger storage engine, MongoDB, by default, uses thesnappy compressor for the journal. To specify a differentcompressions algorithm or no compression for a mongodinstance:

Tip

If you encounter an unclean shutdown for a mongodduring this procedure, you must use the old compressor settings torecover using the journal files. Once recovered, you can retry theprocedure.

  • Standalone
  • Replica Set Member
  • Sharded Cluster Member

Use the following procedure to change the journal compressorfor a standalone mongod instance:

If you use command-line options instead of a configuration file, youwill have to update the —wiredTigerJournalCompressor command-line option duringthe restart below.

  1. db.getSiblingDB('admin').shutdownServer()

  • Once you have confirmed that the process is no longer running,restart the mongod instance:

    • If you are using a configuration file:
  1. mongod -f <path/to/myconfig.conf>
  1. mongod --wiredTigerJournalCompressor <differentCompressor|none>  ...

Use the following procedure to change the journal compressorfor a member of a replica set:

Note

The following procedure involves restarting the replica member as astandalone without the journal.

  1. db.getSiblingDB('admin').shutdownServer()
  1. storage:
  2.    journal:
  3.       enabled: false
  4. #replication:
  5. #   replSetName: replA
  6. setParameter:
  7.    disableLogicalSessionCacheRefresh: true

If you use command-line options instead of a configuration file, youwill have to update the command-line option during the restart.

  • Restart the mongod instance:

    • If you are using a configuration file:
  1. mongod -f <path/to/myconfig.conf>
  1. mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true  ...
  • Perform a clean shutdown of the mongod instance:
  1. db.getSiblingDB('admin').shutdownServer()

Confirm that the process is no longer running.

  1. storage:
  2.    wiredTiger:
  3.       engineConfig:
  4.          journalCompressor: <newValue>
  5. replication:
  6.    replSetName: replA

If you use command-line options instead of a configuration file, youwill have to update the command-line options during the restartbelow.

  • Restart the mongod instance as a replica set member:

    • If you are using a configuration file:
  1. mongod -f <path/to/myconfig.conf>

  • If you are using command-line options instead of a configurationfile:

  1. mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Use the following procedure to change the journal compressorfor a member of a shard replica set or config server replica set:

Note

The following procedure involves restarting the replica member as astandalone without the journal.

  1. db.getSiblingDB('admin').shutdownServer()
  1. storage:
  2.    journal:
  3.       enabled: false
  4. setParameter:
  5.    skipShardingConfigurationChecks: true
  6.    disableLogicalSessionCacheRefresh: true
  7. #replication:
  8. #   replSetName: shardA
  9. #sharding:
  10. #   clusterRole: shardsvr
  11. net:
  12.   port: 27218

If you use command-line options instead of a configuration file, youwill have to update the command-line option during the restart.

  • Restart the mongod instance:

    • If you are using a configuration file:
  1. mongod -f <path/to/myconfig.conf>
  1. mongod --nojournal --setParameter skipShardingConfigurationChecks=true --setParameter disableLogicalSessionCacheRefresh=true --port <samePort> ...
  • Perform a clean shutdown of the mongod instance:
  1. db.getSiblingDB('admin').shutdownServer()

Confirm that the process is no longer running.

  1. storage:
  2.    wiredTiger:
  3.       engineConfig:
  4.          journalCompressor: <newValue>
  5. replication:
  6.    replSetName: shardA
  7. sharding:
  8.    clusterRole: shardsvr
  9. net:
  10.   port: 27218

If you use command-line options instead of a configuration file, youwill have to update the command-line options during the restartbelow.

  • Restart the mongod instance as a replica set member:

    • If you are using a configuration file:
  1. mongod -f <path/to/myconfig.conf>
  1. mongod --shardsvr --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...