[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:
Depends
depends on SERVER-1256 low priority write flag Closed
is depended on by SERVER-1588 mongodump/mongoexport should issue it... Closed
is depended on by TOOLS-131 mongodump/mongoexport should have a -... Closed
is depended on by SERVER-3693 mongod won't become primary if it's f... Closed
is depended on by SERVER-4143 Replication should pause during fsync... Closed
is depended on by SERVER-15861 Add argument to replSetStepDown to al... Closed
Duplicate
is duplicated by SERVER-11970 While fsyncLock() to secondary stopin... Closed
is duplicated by SERVER-2278 A locked mongod can't access a new da... Closed
is duplicated by SERVER-2281 after a {fsync: 1, lock: 1}, "show d... Closed
is duplicated by SERVER-5533 fsync and lock on a Secondary causes ... Closed
is duplicated by SERVER-11119 mongod connections hang because of as... Closed
is duplicated by SERVER-13541 Freeze using mongo + mongodump + fsyn... Closed
is duplicated by SERVER-7711 fsyncLock() makes mongod unusable if ... Closed
is duplicated by SERVER-12577 mongod hangs on shutdown Closed
Gantt Dependency
has to be done after SERVER-8579 Consolidate Mongod Lock/Resource Sche... Closed
Related
related to SERVER-4243 If there is a pending write due to an... Closed
related to SERVER-3950 Add a command to stop/restart replica... Closed
related to DOCS-3681 warn users that fsyncUnlock needs to ... Closed
related to SERVER-8579 Consolidate Mongod Lock/Resource Sche... Closed
related to SERVER-15745 Member should not be electable while ... Backlog
related to SERVER-7948 mongodump should assert that server i... Closed
is related to SERVER-6302 Race condition when multiple fsyncLoc... Closed
is related to SERVER-15946 replSetStepDown without force argumen... Closed
is related to DOCS-1603 Warn that fsyncLock() may prevent bei... Closed
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 ]

Hi qianyiyong@huawei.com,

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...
It's a serious bug!!!

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: SERVER-1423 Global/Flush S acquisitions should set different policy

Global S-mode should set a compatible-first policy in order to allow reads
to happen even if there are writers which might be blocked.
Branch: master
https://github.com/mongodb/mongo/commit/60bde0565d251463b50cee23b49a025d78e2278d

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 years! Causing issues in 2.4.9 as well

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 SERVER-1966

Generated at Thu Feb 08 02:56:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.