[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:
Duplicate
duplicates SERVER-15745 Member should not be electable while ... Backlog
Related
Participants:

 Description   

Repl Members that are fsyncLock'd should not become primary.

Currently with SERVER-11103 being fixed, a replica set member which is SECONDARY and has been issued fsyncLock can become PRIMARY.

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?

Generated at Thu Feb 08 03:43:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.