ExportXMLWordPrintableJSON

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

      Don't vote for a node that is behind the max seen majority commit point. And conversely a node should not run for election if it knows it's behind the majority commit point.

      This should be verified with TLA+ first.

      Two possibilities were considered:

      1. [*Preferred*] A node should refrain from running for election when it knows its lastWrittenOpTime is lower than the known majority commit point. Also a node should not vote for a node with a lastWrittenOpTime lower than the known majority commit point.
        1. If we can’t catch up to the known majority point, the node will never become primary. So that we can't put the majority commit point in jeopardy.
      2. A node can run for election but should not become writable (not leave the catchup phase) until it’s caught up to the known majority commit point. After a timeout it can step-down or crash.
        1. If we can’t catch up to the known majority point, we will see a node flapping between primary/secondary and never become writable.

      AI taken from WRITING-39616.

            Assignee:
            Unassigned
            Reporter:
            Pierre Turin
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: