In the 2.6 docs it was explicitly stated that db.fsyncLock()
should not be used when running mongodump
:
Do not use mongodump with db.fsyncLock().
But this information has disappeared since the 3.0 version of the docs. There is actually no info at all regarding locks in the mongodump
docs from 3.0.
My guess is that, when using --oplog
it is not necessary to call db.fsyncLock()
, but I'm not 100% sure:
Without --oplog, if there are write operations during the dump operation, the dump will not reflect a single moment in time. Changes made to the database during the update process can affect the output of the backup.
Could you help me here? Is it necessary to perform an fsyncLock in MongoDB before creating a dump with mongodump?
thanks!
My guess is that, when using --oplog it is not necessary to call db.fsyncLock()
Previously with MongoDB versions before 3.0 you must not call db.fsyncLock()
when doing a mongodump
and you don't need it now. The warning about not using fsync
with mongodump
was removed at several places at once, so that it doesn't look like an oversight but a deliberate change.
The db.fsyncLock()
documentation states that
This function locks the database and creates a window for backup operations.
But that's only necessary for Backup with cp or rsync. The Back Up and Restore with MongoDB Tools Tutorial doesn't mention any additional locks and explicity mentions that with the --oplog
parameter, you'll get a consistent backup:
Use the
--oplog
option with mongodump to collect the oplog entries to build a point-in-time snapshot of a database within a replica set. With --oplog, mongodump copies all the data from the source database as well as all of the oplog entries from the beginning to the end of the backup procedure. This operation, in conjunction with mongorestore --oplogReplay, allows you to restore a backup that reflects the specific moment in time that corresponds to when mongodump completed creating the dump file.
Conclusion: No, you don't need to call db.fsyncLock()
.