0

figure 8 in raft paper Consider a situation like the figure 8 in raft paper, but in (c), log entry from term 2 has been commited, and s1 crashs, s5 becomes leader, then s5 send append entry rpc to s2, s3, s4, according to the rule, s2, s3, s4 must replace the log entry from term 2 with log entry from term 3, caused the log that has been submitted to be overwritten, how can we avoid that?

I met this kind of situation in 6.824 labs, causes me to sometimes fail the test (very infrequently. Only one or two times out of hundreds)

zelin
  • 1

1 Answers1

0

The issue is with the voting; if there is a committed item X, then a node could be elected only if it has item X in its log. Basically, committed items will never be overridden.

In your case, if S5 doesn't have the latest committed value, it won't be able to get the majority of votes to become a leader.

Quick edit: the key property of raft is that only legit nodes may become leaders. If a leader committed a value and died (even before other nodes learned about the committed index), it guarantees that the majority of nodes have the value. So the next leader will be elected from that set.

AndrewR
  • 1,252
  • 8
  • 7
  • Thanks a lot, your answer really made me understand instantly. It looks like I misunderstood the intent of the raft author, I mistakenly thought that the last log saved in memory was compared during the election, not the last log that had been commited. Thanks a lot! – zelin Feb 07 '23 at 03:48
  • No problem, one more insight - let's say there are 5 nodes, and the leader got confirmations from 2 other - so the consensus is there. The leader may crash just at that moment when consensus reached - even if no one knows about it (as the leader crashed before sharing that). The protocol will guarantee that the value won't be lost, which is pretty nice. What I am trying to say, that there is consensus and there is commit index; clearly consensus comes first, and when it reached, it won't be changed. – AndrewR Feb 07 '23 at 04:01