5
$\begingroup$

In part (c) of Figure 8 in this paper http://ramcloud.stanford.edu/raft.pdf, I am confused how S1 knows that the current term is 4 when it restarts and is elected leader.

Here is the sequence as I currently understand it:

  1. S1 is elected leader for term 2, partially replicates a request, and then dies.
  2. S5 is then elected leader for term 3, receives but does not replicate a request and then dies.
  3. S1 restarts, (still thinking it is term 2), is elected leader (for term 4?), and then replicates a term 2 request to a majority of nodes, but does not commit.

My confusion is in step 3. When S1 reawakens, it is elected leader for term 4, even though it hasn't been active since term 2. How does S1 know that it is now term 4?

Citation for linked paper:

O NGARO , D., AND O USTERHOUT, J. In search of an understandable consensus algorithm. In Proc ATC’14, USENIX Annual Technical Conference (2014), USENIX.

| cite | improve this question | |
$\endgroup$
  • 1
    $\begingroup$ You'll want to read page 4 "Rules For Servers" > "Leaders" for clarification on index consistency. $\endgroup$ – Francesco Gramano Feb 17 '15 at 20:37
  • $\begingroup$ Duly noted. I have added a citation. $\endgroup$ – Bryan Glazer Feb 18 '15 at 19:37
  • $\begingroup$ @FrancescoGramano "If RPC request or response contains term T > currentTerm: set currentTerm = T, convert to follower (§5.1)". So S1 would receive a response to its RequestVote RPC that says the term is actually 4, then it would become a follower, and finally it would timeout, become a candidate and get elected again. All of that before another candidate is elected. Is that correct? This seems incredibly unlikely, but I suppose that's not the point. $\endgroup$ – Bryan Glazer Feb 18 '15 at 19:43
3
$\begingroup$

Server 1 does not immediately know the term when it starts up. Terms and other state such as commit indexes are (normally) held in memory and shared only via RPCs. Therefore, even though server 1 died when it was the leader for term 2, it won't even know about term 2 when it starts back up, let alone term 4.

The way server 1 will learn the term is via AppendEntries and RequestVote RPCs. When server 1 starts, it will initialize its term to 1. If it receives a heartbeat from node 5 before it dies, the heartbeat (an AppendEntries RPC) will contain server 5's term: 3. Given that information, when server 5 dies and server 1's election times out, it will transition to candidate, increment its term to 4, and start the election. This is the likely way in which this scenario might occur since server 2 could also win an election with or without server 1 being alive.

The reason server 1 would need to have been alive for some period of time prior to server 5 crashing is because of server 1 starts a new election immediately after it starts (without having communicated with any other node) it will lose the election since its term (1) will be less than the term of all other servers. In that scenario, server 2 would also start an election and ultimately win before server 1 can update its term and start another election.

| cite | improve this answer | |
$\endgroup$
  • $\begingroup$ Term is persisted on disk, so when a server starts it knows its last term and wont start from term 1 $\endgroup$ – lovesh Mar 26 '17 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.