fsyncLock command and journal

[SeungUck Lee]

Hi.

About fsyncLock command, MongoDB manual says (https://docs.mongodb.com/manual/reference/command/fsync/#dbcmd.fsync)

 

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

I could not find the reason that I should not use fsyncLock() with journal logged MongoDB server.

I have tested recent mongodb version (3.2.8), But there's no difference using fsyncLock between journaling enabled mongodb and not.

Is this recommendation of manaul still valid ?

And one more question about this manual page (https://docs.mongodb.com/manual/reference/method/db.fsyncLock/#db.fsyncLock).

In this manual, 

Connection¶
When calling db.fsyncLock(), ensure that the connection is kept open to allow a subsequent call to db.fsyncUnlock().

But in my test, also no problem to unlock on another sessions, I closed previous locking session. (Not auth is enabled).

Is this only problem with auth enabled mongodb ?

Thanks in advance.

[SeungUck Lee]

Can anyone help me this ?

[Amar]

Hello,

I could not find the reason that I should not use fsyncLock() with journal logged MongoDB server.
I have tested recent mongodb version (3.2.8), But there’s no difference using fsyncLock between journaling enabled mongodb and not.
Is this recommendation of manaul still valid ?

There are two major caveats about using fsyncLock() for backup purposes:

1. fsyncLock() stops all writes to the node, which is very disruptive to the operation of your database.
2. If fsyncLock() is performed on a Secondary node and the backup is taking too long, there is a real risk of the Secondary falling off the oplog and thus must perform an initial sync process again.

For a relatively non-disruptive backup method, you may be able to use Filesystem Snapshots instead.

But in my test, also no problem to unlock on another sessions, I closed previous locking session. (Not auth is enabled).
Is this only problem with auth enabled mongodb ?

Due to potential issues of using fsyncLock() and fsyncUnlock(), you may find other less disruptive backup methods in the MongoDB Backup Methods page.

Regards,

Amar

​

[SeungUck Lee]

Hello Amar.

For a relatively non-disruptive backup method, you may be able to use Filesystem Snapshots instead.

But in my test, also no problem to unlock on another sessions, I closed previous locking session. (Not auth is enabled).
Is this only problem with auth enabled mongodb ?

Due to potential issues of using fsyncLock() and fsyncUnlock(), you may find other less disruptive backup methods in the MongoDB Backup Methods pageΩ

Yes manual also said that, 

So what I am wondering is example case of "potential issues of using fsyncLock() and fsyncUnlock()". 

mongodump and filesystem snapshot is not usable solutions for me.

Thanks

Regards,

Matt

 

[Amar]

Hi Matt,

So what I am wondering is example case of “potential issues of using fsyncLock() and fsyncUnlock()”.
mongodump and filesystem snapshot is not usable solutions for me.

fsynclock() will lock the whole instance for writes, and in some cases, reads. While the command allows you to ensure that the database is in a frozen, consistent state and remains in that state until you unlock it, it is disruptive to your operation unless you can be certain that during the time the database is locked, it will not be used.

Also, due to the nature of the fsyncLock() command, the session that perform the lock should stay open to unlock the database in a later time. Otherwise, there are no guarantees that a new session would be able to unlock the database and the only solution to unlock the database would be a hard restart (i.e. by using the kill command in Unix).

Regards,

Amar

​

[SeungUck Lee]

Hi Amar.

Thanks for your detailed explanation.

[Albert Nurgaliev]

Hello, Amar, thank you for your explanations,

I have re-read the documentations multiple times but still uncertain about the need to fsyncLock the database if journaling enabled. In my case I'm planning to use filesystem snapshot on a mongo instance where data files and journaling are on the same volume and I'm using LVM. Is it really needed to have a database locked if journaling enabled? I realize that locking is preferred action, but even if I will perform on a secondary node which has the read concern is set to primary only, I would prefer not to lock the database if that would not corrupt by database when I restore such snapshot. Any suggestions?

[Stephen Steneker]

On Wednesday, 28 June 2017 06:08:29 UTC+10, Albert Nurgaliev wrote:

I have re-read the documentations multiple times but still uncertain about the need to fsyncLock the database if journaling enabled. In my case I'm planning to use filesystem snapshot on a mongo instance where data files and journaling are on the same volume and I'm using LVM. Is it really needed to have a database locked if journaling enabled? I realize that locking is preferred action, but even if I will perform on a secondary node which has the read concern is set to primary only, I would prefer not to lock the database if that would not corrupt by database when I restore such snapshot. Any suggestions?

Hi Albert,

If you have journaling enabled and your data files and journal are on the same volume, there is no requirement to fsyncLock when taking LVM snapshots.

For more information see: Back Up and Restore with Filesystem Snapshots.

If you have further questions, in future please start a new discussion with details specific to your environment (MongoDB server version, deployment type, storage engine) rather than resurrecting old threads.

Thanks,

Stennie