Navigation
This version of the documentation is archived and no longer supported.

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 or storage.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.

  1. Create a temporary directory into which to create a set of journal files:

    mkdir ~/tmpDbpath
    
  2. Create a set of journal files by starting a mongod instance that uses the temporary directory. For example:

    mongod --port 10000 --dbpath ~/tmpDbpath --journal --bind_ip localhost,<hostname(s)|ip address(es)> --storageEngine mmapv1
    

    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.

  3. When you see the following log output, indicating mongod has the files, press CONTROL+C to stop the mongod instance:

    ... NETWORK  [initandlisten] waiting for connections on port 10000
    
  4. 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:

    mv ~/tmpDbpath/journal /data/db/
    
  5. Start the new mongod instance. For example:

    mongod --port 27017 --dbpath /data/db --journal --bind_ip localhost,<hostname(s)|ip address(es)> --storageEngine mmapv1
    

    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.

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

  1. 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.

  2. Perform a clean shutdown of the mongod instance. For example, connect a mongo shell to the instance and issue db.shutdownServer():

    db.getSiblingDB('admin').shutdownServer()
    
  3. Once you have confirmed that the process is no longer running, restart the mongod instance:

    • If you are using a configuration file:

      mongod -f <path/to/myconfig.conf>
      
    • If you are using command-line options instead of a configuration file, update the --wiredTigerJournalCompressor option.

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

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.

  1. Perform a clean shutdown of the mongod instance. For example, connect a mongo shell to the instance and issue db.shutdownServer():

    db.getSiblingDB('admin').shutdownServer()
    
  2. Update the configuration file to prepare to restart as a standalone:

    For example:

    storage:
       journal:
          enabled: false
    #replication:
    #   replSetName: replA
    setParameter:
       disableLogicalSessionCacheRefresh: true
    

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

  3. Restart the mongod instance:

    • If you are using a configuration file:

      mongod -f <path/to/myconfig.conf>
      
    • If you are using command-line options instead of a configuration file,

  4. Perform a clean shutdown of the mongod instance:

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

    Confirm that the process is no longer running.

  5. Update the configuration file to prepare to restart as a replica set member with the new journal compressor:

    For example:

    storage:
       wiredTiger:
          engineConfig:
             journalCompressor: <newValue>
    replication:
       replSetName: replA
    

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

  6. Restart the mongod instance as a replica set member:

    • If you are using a configuration file:

      mongod -f <path/to/myconfig.conf>
      
    • If you are using command-line options instead of a configuration file:

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

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.

  1. Perform a clean shutdown of the mongod instance. For example, connect a mongo shell to the instance and issue db.shutdownServer():

    db.getSiblingDB('admin').shutdownServer()
    
  2. Update the configuration file to prepare to restart as a standalone:

    For example:

    storage:
       journal:
          enabled: false
    setParameter:
       skipShardingConfigurationChecks: true
       disableLogicalSessionCacheRefresh: true
    #replication:
    #   replSetName: shardA
    #sharding:
    #   clusterRole: shardsvr
    net:
      port: 27218
    

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

  3. Restart the mongod instance:

  4. Perform a clean shutdown of the mongod instance:

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

    Confirm that the process is no longer running.

  5. Update the configuration file to prepare to restart with the new journal compressor:

    For example:

    storage:
       wiredTiger:
          engineConfig:
             journalCompressor: <newValue>
    replication:
       replSetName: shardA
    sharding:
       clusterRole: shardsvr
    net:
      port: 27218
    

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

  6. Restart the mongod instance as a replica set member:

←   Journaling GridFS  →