-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Replication
-
ALL
Whenever a node votes in an election, it records the current term in a LastVote object, to ensure it doesn't vote again in the same term. The LastVote object is stored in memory, and to disk as a singleton document in the local.replset.election collection.
The LastVote object has two fields, term and candidateIndex. The term field is crucial, but the candidateIndex field is used only for logging and statistics. This is a good thing, because candidateIndex is unsafe to use. It is the index of the candidate in a particular version of the replica set config, but this config's version number isn't stored alongside candidateIndex, and the config can change at any time. If the replica set membership changes then candidateIndex may refer to the wrong node in the new config. If nodes are removed then candidateIndex may be out of range, and we risk crashing with an invariant by calling config.getMemberAt(candidateIndex). The field currently causes wrong stats and logging, and it's a bug waiting to happen.
Proposal: We can't easily remove the field, because MongoDB currently requires this field to be present in the on-disk document or it will fail to parse. Let's go through a two-release deprecation cycle that first makes the field optional but still present, then deletes the field. Meanwhile, delete LastVote::getCandidateIndex() and all its uses.
- is duplicated by
-
SERVER-58787 Incorrect use of candidateIndex from a previous config during vote processing.
- Closed
- is related to
-
SERVER-46667 Avoid invariant from invalid candidateIndex
- Closed