Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-47007

candidateIndex field of LastVote document is meaningless

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 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.

            Assignee:
            backlog-server-repl [DO NOT USE] Backlog - Replication Team
            Reporter:
            jesse@mongodb.com A. Jesse Jiryu Davis
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: