[SERVER-1423] reads often aren't possible while in fsync and lock mode Created: 15/Jul/10 Updated: 12/Jul/16 Resolved: 14/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0-rc1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dwight Merriman | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 54 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
reads are possible in fsync and lock, but if anyone tries a write, the rwlock will then block all readers. |
| Comments |
| Comment by Kaloian Manassiev [ 29/Oct/15 ] |
|
If you are able to reproduce fsyncLock blocking readers in MongoDB 3.0+, would it be possible to file a new jira ticket and attach the output from running 'db.currentOp(true)' so we can investigate? Thank you in advance. -Kal. |
| Comment by qianyiyong [ 29/Oct/15 ] |
|
version 2.6.5, 3.0.4 still have this problem, in a heavy test, the mongod will hang, all db.x commond or show dbs will hang... |
| Comment by Githook User [ 14/Nov/14 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: Global S-mode should set a compatible-first policy in order to allow reads |
| Comment by Thomas Rueckstiess [ 15/Apr/14 ] |
|
This has been touched on before in this ticket and the duplicates, but I want to make it explicit: This issue also affects signal handling. An fsyncLocked mongod with auth enabled cannot be killed, except with a hard SIGKILL (-9). Other signals like SIGTERM (-15), SIGUSR1 (-30) are blocked. This affects all recent versions including 2.6.0. |
| Comment by Egan Neuhengen [ 04/Apr/14 ] |
|
Thanks Dwight! |
| Comment by Dwight Merriman [ 04/Apr/14 ] |
|
ok i raised it to major |
| Comment by Egan Neuhengen [ 04/Apr/14 ] |
|
Same as Robin. I don't understand why this is listed as an "improvement" for a distant release - this is a serious bug in the function that makes it both dangerous and completely unusable for mongo-recommended purposes. Requires us to hard-crash mongod (since a clean shutdown requires reading the database!). |
| Comment by Robin Yarbrough [ 04/Apr/14 ] |
|
I've seen this while trying to do a backup of a hidden replica set. We issue db.fsyncLock() then copy data, while data is copying mms can't ping and when i try to get into mongo from another shell it hangs. Once the data is finished copying, we try to issue db.fsyncUnlock() but command hangs. Had to restart server to remove lock. |
| Comment by Johnny Boy [ 03/Apr/14 ] |
|
Bump, this has been here for 4 |
| Comment by Appnique OMS [ 05/Dec/13 ] |
|
is it fixed in 2.4.7? .because having this issue on 2.4.7. |
| Comment by Philip Hadviger [ 11/Sep/13 ] |
|
Any chance this will make it into 2.5.x? It's still causing problems for us on 2.4.5. |
| Comment by Justin Parsons [ 08/Mar/13 ] |
|
You sir, just made my day!!! Thank you! |
| Comment by Dwight Merriman [ 06/Feb/12 ] |
|
fixing this for 2.1.x. will properly maintain read-lockability the whole time. however i believe a write lock is necessary to open a database and i wonder if that is still going to be an issue, perhaps 100x less frequent but making a note here regarding that. |
| Comment by Benedikt Waldvogel [ 18/Oct/10 ] |
|
this might be related to |