Incorrect use of candidateIndex from a previous config during vote processing.

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Duplicate
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Replication
    • None
    • Replication
    • ALL
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      After we granted vote for a node in config C0, and recorded the `candidateIndex` in `lastVote`, later we could install a new config C1 from another node due to heartbeat, and next time when we are voting, our `_rsConfig` is already a new one, but the `candidateIndex` was based on an old config, so calling `_rsConfig.getMemberAt(_lastVote.getCandidateIndex())` is not correct. This would result in incorrect logs and metrics. Ideally we should record in `_lastVote` the direct information of the candidate node (like memberId and host/port) instead of an index which can vary across configs. This is regardless of using the strict config term/version comparison rule or the relaxed one.

              Assignee:
              [DO NOT USE] Backlog - Replication Team
              Reporter:
              Wenbin Zhu
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: