7 / 7 Consensus: Raft, Paxos & Leader Election

Majority Is Not Committed

A five-server Raft cluster. Entry 1:2 (index 1, term 2) is committed on all five. Then:

phase what happened who holds index 2
term 5 S1 leads, appends 2:5, replicates to S2, then crashes S1, S2
term 6 S5 is elected with votes from S3, S4 and itself, appends 2:6 locally, crashes before replicating S1, S2 hold 2:5; S5 holds 2:6
term 7 S1 restarts, is elected, and successfully replicates 2:5 to S3 S1, S2, S3 hold 2:5

S1 is now leader in term 7 and entry 2:5 is stored on three of five servers. May S1 mark index 2 committed and apply it?

A

No. An entry inherited from a previous term commits only once it is stored on every server, since any missing server could later be elected and overwrite it.

B

No. 2:5 is from an earlier term, so counting replicas proves nothing. S1 must first get an entry from term 7 onto a majority; index 2 then commits indirectly.

C

Yes. An entry on a majority is committed by definition, and three of five is a majority.

D

Yes, and more safely than usual, because term 5 is lower than S1's current term 7, so no future leader can carry an entry that outranks it at index 2.