Docs Menu
Docs Home
/
MongoDB Manual
/ / /

db.fsyncUnlock()

On this page

  • Definition
  • Compatibility
  • Compatibility with WiredTiger
  • Example
db.fsyncUnlock()

Reduces the lock count on the server to renable write operations.

Starting in MongoDB 7.1 (also available starting in 7.0.2, 6.0.11, and 5.0.22) the db.fsyncLock() and db.fsyncUnlock() methods can run on mongos to lock and unlock a sharded cluster.

Important

mongosh Method

This page documents a mongosh method. This is not the documentation for database commands or language-specific drivers, such as Node.js.

For the database command, see the fsyncUnlock command.

For MongoDB API drivers, refer to the language-specific MongoDB driver documentation.

Servers maintain an fsync lock count. The fsyncLock() method increments the lock count while the fsyncUnlock() method decrements it. To unlock writes on a server or cluster, call the fsyncUnlock() method until the lock count reaches zero.

db.fsyncUnlock() is an administrative operation. Use this method to unlock a server or cluster after a backup operation

db.fsyncUnlock() has the syntax:

db.fsyncUnlock()

The operation returns a document with the following fields:

info
Information on the status of the operation.
lockCount
The number of locks remaining on the instance after the operation.
ok
The status code.

The db.fsyncUnlock() method wraps the fsyncUnlock command.

This method is available in deployments hosted in the following environments:

  • MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud

Important

This command is not supported in M0, M2, and M5 clusters. For more information, see Unsupported Commands.

db.fsyncLock() 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.

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 Backup Methods for a Self-Managed Deployment.

Consider a situation where db.fsyncLock() has been issued two times. The following db.fsyncUnlock() operation reduces the locks taken by db.fsyncLock() by 1:

db.fsyncUnlock()

The operation returns the following document:

{ "info" : "fsyncUnlock completed", "lockCount" : NumberLong(1), "ok" : 1 }

As the lockCount is greater than 0, the mongod instance is locked against writes. To unlock the instance for writes, run db.fsyncLock() again:

db.fsyncUnlock()

The operation returns the following document:

{ "info" : "fsyncUnlock completed", "lockCount" : NumberLong(0), "ok" : 1 }

The mongod instance is unlocked for writes.

Back

db.fsyncLock