[SERVER-21062] A REMOVED node that is ahead of the other nodes in the set can prevent a primary from being elected Created: 21/Oct/15 Updated: 27/Oct/15 Resolved: 23/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.2.0-rc0 |
| Fix Version/s: | 3.2.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Timothy Olsen (Inactive) | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Following an upgrade of mmapv1 SCCC config servers to CSRS, I sometimes (about 60% of the time) see the new replica set get stuck without a primary after the first config server is restarted without --configsvrMode=sccc set and enters the REMOVED state. The remaining 3 replica set members stay in SECONDARY state. This is with commit dbbc9a2e3d8c4d7fe1748fa980ba7d01b9489dbe. rs.status():
I will attach logs. |
| Comments |
| Comment by Githook User [ 23/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 23/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, different case which we can create an issue for. For now, removed nodes should not block elections. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 23/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
A priority 0 node that is in state SECONDARY could become the sync source for the electable secondaries, which is different from this case, maybe. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 23/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Good catch. We call that function as part of the pv0 priority election algorithm, as well as in getUnelectableReason() and getMyUnelectableReason(). Those latter two should only take effect under pv0 and not pv1. They should be removed for Raft. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Siyuan Zhou [ 23/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
If TopologyCoordinatorImpl::_isOpTimeCloseEnoughToLatestToElect is the reason of this problem, it could happen on a node with priority 0 but having a uncommitted oplog ahead of other secondaries. If this node is the only one that has the uncommitted oplog after the previous primary crashes, it will prevents others from electing themselves. Shall we remove this rule for protocol version 1, as it is not compatible with RAFT? Generally, protocol version 1 should not rely on the absolute timestamp. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
waiting for replication works! thanks! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
yes, thanks! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Spencer Brody (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, assuming you meant to include "are the same" somewhere in that statement | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
spencer Would checking that the optimes reported from rs.status() across all the nodes do the trick? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Spencer Brody (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks tim.olsen. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Ok. I had to reproduce the problem again as I don't currently have access to the original reproduction of the problem. I've attached a tarball with everything relevant for the new reproduction: rs.status(), rs.conf(), logfiles, and oplogs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 22/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
tim.olsen , can you attach the oplogs from the 4 servers to the ticket? I'm curious if there are two problems, here. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Spencer Brody (Inactive) [ 21/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Okay, I think I know what's going on: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 21/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note that this was not happening with 3.1.8 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 21/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Log files attached. I have tried to make the filenames of the logs self descriptive. Let me know if you have any questions. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Timothy Olsen (Inactive) [ 21/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sure, here's the rs.conf():
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 21/Oct/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Can you attach the replica set configuration document to the ticket, please? |