db.fsyncUnlock()
Definition
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()
anddb.fsyncUnlock()
methods can run onmongos
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 thefsyncUnlock()
method decrements it. To unlock writes on a server or cluster, call thefsyncUnlock()
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 operationdb.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 thefsyncUnlock
command.
Compatibility
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.
MongoDB Enterprise: The subscription-based, self-managed version of MongoDB
MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB
Compatibility with WiredTiger
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.
Example
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.