fsync¶

On this page

Definition
Considerations
Examples

Definition¶

fsync¶

Forces the mongod process to flush all pending writes from the storage layer to disk and locks the entire mongod instance to prevent additional writes until the user releases the lock with a corresponding fsyncUnlock. Optionally, you can use fsync to lock the mongod instance and block write operations for the purpose of capturing backups.

As applications write data, MongoDB records the data in the storage layer and then writes the data to disk within the syncPeriodSecs interval, which is 60 seconds by default. Run fsync when you want to flush writes to disk ahead of that interval.

The fsync command has the following syntax:

copy

{ fsync: 1, async: <Boolean>, lock: <Boolean> }

The fsync command has the following fields:

Field	Type	Description
`fsync`	integer	Enter “1” to apply `fsync`.
`async`	boolean	Optional. Runs `fsync` asynchronously. By default, the `fsync` operation is synchronous.
`lock`	boolean	Optional. Locks `mongod` instance and blocks all write operations.

Considerations¶

Changed in version MongoDB: 3.2

fsync command with the lock option ensures that the data files are safe to copy using low-level backup utilities such as cp, scp, or tar. A mongod started using the copied files contains user-written data that is indistinguishable from the user-written data on the locked mongod.

Prior to MongoDB 3.2, fsync command with the lock option cannot guarantee that WiredTiger data files are safe to copy using low-level backup utilities.

The data files of a locked mongod may change due to operations such as journaling syncs or WiredTiger snapshots. While this has no affect on the logical data (e.g. data accessed by clients), some backup utilities may detect these changes and emit warnings or fail with errors. For more information on MongoDB- recommended backup utilities and procedures, see MongoDB Backup Methods.

Impact on Larger Deployments¶

An fsync lock is only possible on individual mongod instances of a sharded cluster, not on the entire cluster. To back up an entire sharded cluster, please see Backup and Restore Sharded Clusters for more information.

Alternatives with Journaling¶

If your mongod has journaling enabled, consider using another method to create a backup of the data set.

Impact on Read Operations¶

After fsync with the lock option runs on a mongod, all write operations will block until a subsequent unlock. Read operations may also block. As a result, fsync with lock is not a reliable mechanism for making a mongod instance operate in a read-only mode.

Important

Blocked read operations prevent verification of authentication. Such reads are necessary to establish new connections to a mongod that enforces authorization checks.

Warning

When calling fsync with the lock option, ensure that the connection remains open to allow a subsequent call to db.fsyncUnlock().

Closing the connection may make it difficult to release the lock.

Examples¶

Run Asynchronously¶

The fsync operation is synchronous by default. To run fsync asynchronously, use the async field set to true:

copy

{ fsync: 1, async: true }

The operation returns immediately. To view the status of the fsync operation, check the output of db.currentOp().

Lock `mongod` Instance¶

Note

Changed in version MongoDB: 3.2

fsync command with the lock option ensures that the data files are safe to copy using low-level backup utilities such as cp, scp, or tar. A mongod started using the copied files contains user-written data that is indistinguishable from the user-written data on the locked mongod.

Prior to MongoDB 3.2, fsync command with the lock option cannot guarantee that WiredTiger data files are safe to copy using low-level backup utilities.

The data files of a locked mongod may change due to operations such as journaling syncs or WiredTiger snapshots. While this has no affect on the logical data (e.g. data accessed by clients), some backup utilities may detect these changes and emit warnings or fail with errors. For more information on MongoDB- recommended backup utilities and procedures, see MongoDB Backup Methods.

The primary use of fsync is to lock the mongod instance in order to back up the files within mongod’s dbPath. The operation flushes all data to the storage layer and blocks all write operations until you unlock the mongod instance.

To lock the database, use the lock field set to true:

copy

{ fsync: 1, lock: true }

You may continue to perform read operations on a mongod instance that has a fsync lock. However, after the first write operation all subsequent read operations wait until you unlock the mongod instance.

Unlock `mongod` Instance¶

To unlock the mongod, use db.fsyncUnlock():

copy

db.fsyncUnlock();

Check Lock Status¶

To check the state of the fsync lock, use db.currentOp(). Use the following JavaScript function in the shell to test if mongod instance is currently locked:

copy

serverIsLocked = function () {
                     var co = db.currentOp();
                     if (co && co.fsyncLock) {
                         return true;
                     }
                     return false;
                 }

After loading this function into your mongo shell session call it, with the following syntax:

copy

serverIsLocked()

This function will return true if the mongod instance is currently locked and false if the mongod is not locked.

← dropIndexes clean →

fsync¶

Definition¶

Considerations¶

Impact on Larger Deployments¶

Alternatives with Journaling¶

Impact on Read Operations¶

Examples¶

Run Asynchronously¶

Lock mongod Instance¶

Unlock mongod Instance¶

Check Lock Status¶

Lock `mongod` Instance¶

Unlock `mongod` Instance¶