fsync Command

v1.4+

fsync Command

The fsync command allows us to flush all pending writes to datafiles.  More importantly, it also provides a lock option that makes backups easier.

The fsync command forces the database to flush all datafiles:

> use admin
> db.runCommand({fsync:1});

By default the command returns after synchronizing.  To return immediately use:

> db.runCommand({fsync:1,async:true});

To fsync on a regular basis, use the --syncdelay command line option (see mongod --help output).  By default a full flush is forced every 60 seconds.

Lock, Snapshot and Unlock

With journaling enabled, you may not need to lock at all for a snapshot. See the backups page.

The fsync command supports a lock option that allows one to safely snapshot the database's datafiles. While locked, all write operations are blocked, although read operations are still allowed. After snapshotting, use the unlock command to unlock the database and allow locks again. Example:

 > use admin
switched to db admin
> db.runCommand({fsync:1,lock:1})
{
	"info" : "now locked against writes",
	"ok" : 1
}
> db.currentOp()
{
	"inprog" : [
	],
	"fsyncLock" : 1
}

>// do some work here: for example, snapshot datafiles...
>// runProgram("/path/to/my-filesystem-snapshotting-script.sh")

> db.$cmd.sys.unlock.findOne();
{ "ok" : 1, "info" : "unlock requested" }
> // unlock is now requested.  it may take a moment to take effect.
> db.currentOp()
{ "inprog" : [ ] }

Caveats

While the database can be read while locked for snapshotting, if a write is attempted, this will block readers due to the database's use of a read/write lock. This should be addressed in the future : https://jira.mongodb.org/browse/SERVER-4243

Snapshotting Slaves

The above procedure works on replica slaves. The slave will not apply operations while locked. However, see the above caveats section.

Sharding

The fsync command can only be sent to a single node, not to the entire sharded cluster.

v2.0+ Notes

Shell Helpers

db.fsyncLock() and db.fsyncUnlock() are thin wrappers around the interface documented above. You can see their implementation below:

> db.fsyncLock
function () {
    return db.adminCommand({fsync:1, lock:true});
}
> db.fsyncUnlock
function () {
    return db.getSiblingDB("admin").$cmd.sys.unlock.findOne();
}

Calls to unlock now block

More significantly, the unlock command has slightly modified semantics. Prior to v2.0, the command would request an unlock and return immediately. This made it difficult to know for certain whether the database had, in fact, been unlocked.

This command now blocks until the database is unlocked. When it returns, you can be certain that the databased has synced the datafiles to disk and is again ready to be written to.

See Also

• Backups