[SERVER-15946] replSetStepDown without force argument will fail if secondaries are behind and there is any write load Created: 04/Nov/14 Updated: 11/Jul/16 Resolved: 20/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Matt Dannenberg |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Because the lock manager assigns locks to operations in FIFO order, if a write comes in after replSetStepDown acquires the global lock in MODE_S, but before any secondary has caught up to the head of the oplog, secondaries' attempts to read the oplog will block behind the write's attempt to get the global lock in MODE_IX. Since replSetStepDown took the global lock in MODE_S exactly to block writes, we need some way to indicate to the lock manager that it should continue to grant compatible lock requests, effectively letting reads cut ahead of the blocked writes. |
| Comments |
| Comment by Githook User [ 20/Nov/14 ] |
|
Author: {u'username': u'dannenberg', u'name': u'matt dannenberg', u'email': u'matt.dannenberg@10gen.com'}Message: |
| Comment by Githook User [ 20/Nov/14 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |
| Comment by Githook User [ 20/Nov/14 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |