[SERVER-17015] Repl Members that are fsyncLock'd should not become primary Created: 22/Jan/15 Updated: 12/Jun/15 Resolved: 12/Jun/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Hows | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Repl Members that are fsyncLock'd should not become primary. Currently with From a high level, this seems counter productive, as we want the new primary available to take writes. Can we make it so that members which are under an fsyncLock block themselves from becoming primary. As part of this change, it may be worthwhile investigating the possibility of an indicator about fsyncLock within the output of rs.status() so end-users can isolate election problems with one command. |
| Comments |
| Comment by Scott Hernandez (Inactive) [ 12/Jun/15 ] |
|
dup of SERVER-15745 |
| Comment by Eric Milkie [ 23/Jan/15 ] |
|
I think a use case for fsync-lock is to do reads via mongodb tools to back up data, so I think it wouldn't be advisable to go into maintenance mode for fsync/lock. |
| Comment by Andy Schwerin [ 23/Jan/15 ] |
|
The fsyncLocked node would have to be at least as caught up as other electable nodes for it to stand for election. If writes were coming into the system during the period that the secondary was fsyncLocked, I would expect it to be too far behind to stand for election if any other viable node existed. As such, I would be a little surprised if this issue cropped up in the field. Would you want fsync-locked nodes to continue to serve reads, or would it be sufficient for them to enter the RECOVERING state until they were unlocked? |