-
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:
- [*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.
- 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.
- 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.
- 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.