Question about Committing entries from previous terms

[Jaedong Tang]

I have a question about "Committing entries from previous terms", which is 5.4.2 in the paper.

        "Only log entries from the leader’s current term are committed by counting replicas; once an entry from the current term has been committed in this way, then all prior entries are committed indirectly because of the Log Matching Property." 

My question is how a old entry to be committed indirectly?

Suppose the case (c) in figure 8:

"S5 crashes; S1 restarts, is elected leader, and continues replication. At this point, the log entry from term 2 has been replicated on a majority of servers, but it is not committed".  

1)If it moves to case (d), and log entry from term 3 has already been replicated in all the servers. Can raft decide to make term 3 committed  now because  all the servers contain it even though the current term is 4, or raft still does not commit term 3 until a future log entry(from term 4, for example) is generated and committed?

2)If case (c) moves to case (e), when the log entry from term 4 has been replicated on majority of servers(s1, s2, s3), then term 4 would be committed since the current term is 4. After committing the term 4, the term 2(which has not been committed yet) would "automatically" be committed? Do I understand the "all prior entries are committed indirectly" correctly?

I appreciate your help.

[Oren Eini (Ayende Rahien)]

How Raft commits?

It send the "this is the commited entry id" to the followers.

At that point, followers do something like:

for entry in GetEntries(lastCommited, newCommited):

   entry.Commit();

It doesn't matter what term the entry is, we just commit everything from the last item to the new index we got.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jaedong Tang]

Hi, Ayende

How are about the commitment of pervious term for leader? I mean a new leader just win the election, it only contains some uncommitted log entries from previous terms, and assuming there is no new command from its current term received. That is exactly what happened in figure 8 from (c) to (d):  

 

Server 5 becomes the leader, and it only contains log entries from term 3(and earlier). Assume that there is no command from term 4 issued by any client, eventually all the followers would replicate the same logs as leader, and that is what happened in (d).

Here is my question: according to the paper, "Raft never commits log entries from previous terms by counting replicas(5.4.2)". In this case where all the servers contains log entry from term 3, but the current term is 4. Should raft commit the log entry from term 3 OR it have to wait for new command from term 4 so that it could commit entry from term 3 indirectly? 

在 2016年10月2日星期日 UTC-4上午4:34:03，Ayende Rahien写道：

To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

The way it works, after winning the election, the leader MUST commit a no-op entry to the log.

Only after that it can be considered the active leader.

To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+unsubscribe@googlegroups.com.

[Jaedong Tang]

Thanks for your reply. 

在 2016年10月11日星期二 UTC-4上午4:08:15，Ayende Rahien写道：

[jordan.h...@gmail.com]

What this effectively means in terms of code is: once a leader is elected, even though it knows all the entries in its log are stored on a majority of servers (since it got elected) it can't just commit them because there are cases where they could be removed. This simply means the leader doesn't change its commitIndex, doesn't send any updated commitIndex to followers, and doesn't apply any entries to its state machine. It writes a no-op entry to its log, and only once the leader knows that entry has been replicated to a majority of the cluster does it increment its commitIndex and apply all the entries from the prior commitIndex to the new commitIndex. The leader will simply never set its commitIndex to an index from another term.

[Oren Eini (Ayende Rahien)]

I don't think that your description is accurate.

The leader knows that its log is the most advanced, but it DOESN'T know that its entries are in the majority.

Assume that entries [1 .. 5] are across all servers, and one server has entries [1...7].

That one will become the leader, then it can't commit 6 & 7.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "raft-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+unsubscribe@googlegroups.com.