hesela.devRaft joint consensus
Raft joint consensus is a transitional membership configuration requiring separate majorities of the old and new voting configurations.
The original transition commits a joint configuration before recording the final configuration. Elections and commitment in the joint phase require both majorities, not merely a majority of their union. This is the paper's membership mechanism. [1]
The raft v3.6.0 library exposes joint changes through ConfChangeV2 and requires compatible nodes. For an accepted committed configuration change, the application calls ApplyConfChange and records the returned configuration state in snapshots. Library support does not mean every service uses the same membership workflow. [2]
Constructed example: old {A, B, C}, new {C, D, E}. Count affirmative votes for the same candidate in the same term. C, D, E give old 1/3 and new 3/3: a 3/5 union majority is insufficient. The election is not necessarily lost; more votes may arrive. A, C, D give 2/3 in each; A, B, D, E also satisfy both counts without C. This is a tally example, not a complete election or cluster test. [4]
Relations
- related
- Raft, Quorum intersection
Limitations
- For fixed active old {A, B, C} and new {C, D, E}, constructed matched-prefix indices A=4, B=4, C=8, D=8, E=8 give group bounds 4 and 8. JointConfig.CommittedIndex takes their minimum: candidate 4. Counting the union yields 8. Assume prefix matches against the same leader log, not arbitrary local log lengths; this is not a cluster experiment. [4, 6]
- The helper alone does not make the final commit decision. The leader's current term is passed to raftLog.maybeCommit, which advances only beyond the existing commit index with a matching nonzero term. An older-term candidate alone cannot establish new commitment by replica counting. Entries already committed remain committed; a later current-term commitment covers its older prefix indirectly. [7, 5, 1]
Citations
- Ongaro and Ousterhout: In Search of an Understandable Consensus Algorithm, extended version (20 May 2014), sections 5.4, 6 and 8.
- raft v3.6.0: Node configuration-change and application interfaces
- raft v3.6.0: JointConfig.VoteResult requires both majorities and distinguishes pending from lost
- raft v3.6.0: raftLog.maybeCommit and matchTerm, advancement and current-term guard
- raft v3.6.0: MajorityConfig.CommittedIndex, majority-supported replicated prefix
- raft v3.6.0: raft.maybeCommit passes the leader term and tracker candidate to the log