Term Nine Comes Knocking

A five-server Raft cluster is partitioned for two minutes. S1, S2 and S3 are on the majority side; S4 and S5 are isolated.

S1, S2 and S3 hold a majority; S4 and S5 are isolated majority side isolated side S1 S2 S3 S4 S5 leader, term 4 elections keep timing out

The link is restored. State at that instant:

server currentTerm log, as index:term
S1 (leader) 4 1:1, 2:1, 3:4, 4:4, 5:4
S2 4 1:1, 2:1, 3:4, 4:4, 5:4
S3 4 1:1, 2:1, 3:4, 4:4, 5:4
S4 9 1:1, 2:1
S5 9 1:1, 2:1

S4's election timer fires first after the heal and it broadcasts RequestVote for term 10. What happens next?

A

S4 loses the vote, and nothing else changes. Rejecting a candidate leaves the incumbent's term and leadership untouched, so S1 keeps committing without interruption.

B

S1 steps down, because any RPC carrying a higher term forces that. S4 still loses the vote, because its last log entry is behind. The cluster is leaderless for about one election timeout, then S1, S2 or S3 wins in term 10 or later, and entries 3 through 5 survive.

C

S4 wins. It carries the highest term, and term is the tiebreaker Raft uses to decide which server is authoritative after a partition.

D

S1 rejects the RequestVote and keeps leading in term 4. It is still receiving heartbeat acknowledgements from a majority, so its leadership is intact and its term is unchanged.