-
Type:
Bug
-
Resolution: Done
-
Priority:
Critical - P2
-
Affects Version/s: 2.1.2
-
Component/s: Concurrency
-
None
-
Fully Compatible
-
Integration 2016-10-31, Query 2016-11-21
-
(copied to CRM)
There is currently no specification for multiple agents attempting to fsyncLock() a mongod instance. However, the observed behavior is somewhat confusing. Observed behavior, from a single mongo shell:
> db.runCommand({fsync: 1, lock: true})
{
"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
"ok" : 1
}
> db.runCommand({fsync: 1, lock: true})
{
"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
"ok" : 1
}
> db.fsyncUnlock()
{ "ok" : 1, "info" : "unlock completed" }
> db.fsyncUnlock()
{ "ok" : 1, "info" : "unlock completed" }
> db.fsyncUnlock()
At first blush, this appears like the fsyncLock is a shared, recursive resource, and every acquisition must be paired with a release. However, this is misleading. What in fact happens is that the second acquisition returns, reporting success, if the first acquirer has the lock, and in the background on mongod, the lock request gets queued up. When the first acquisition is released with fsyncUnlock(), the pending lock request gets processed, and the fsync lock is re-acquired. There is a brief period where the fsync lock is unheld.
We should:
- Fix the race condition, maintaining a locked read-only file set until all clients have unlocked.
- Make lock state clearer to clients, so that the message provides the information needed to understand current state.
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
SERVER-26875 Create FSM test that exercises concurrent fsyncLock & fsyncUnlock
-
- Closed
-
- related to
-
SERVER-1423 reads often aren't possible while in fsync and lock mode
-
- Closed
-