the definition about committed

[yang...@gmail.com]

I'm reading the paper 'In Search of an Understandable Consensus Algorithm' now. But I'm not sure about the definition of committed Entry. Could anyone help me out ?

The definition of commit

the contradict with the definition above. According to the definition, the log entry from term 2 is committed.

[Oren Eini (Ayende Rahien)]

A log entry can have several states.

1) It is in the log, but not in the majority of logs

2) It is in the majority of the logs, but not committed

3) It is committed, which require that it is in the majority of the logs.

Consider state e in the image. 

Index 3, term 4 is actually in a majority of the cluster. That means that it will eventually be committed. But it may take a while for a leader to confirm that it was indeed replicated to a majority.

For example, S1 may have received the log entry, but is unable to talk to the leader to confirm it. 

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.

[yang...@gmail.com]

Very clear. Thanks very much.

在 2016年12月28日星期三 UTC+8下午2:14:53，Ayende Rahien写道：

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

[bo yang]

So the second state for log entry is indirectly committed?

在 2016年12月28日星期三 UTC+8下午2:14:53，Ayende Rahien写道：

A log entry can have several states.

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

[Kijana Woodard]

If "indirectly" also means "not".

IoW, from our birds eye view of Figure 8, we can reason that it will eventually be committed, but from the pov of any single node or any single client, this is not knowable. For all they know, they might be transitioning from (c) to (d) instead of from (c) to (e).

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

[Hui Kang]

In the Figure 8, in step (c), what if the log entry index 2 is commited to s1, s2, and s3. In this case, when s5 becomes the leader in (d), will it override the log index 2 of s1, s2, and s3? If so, this invalidate the leader completeness property.

- Hui

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

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

This is why the leader in C must ensure an entry from its *current term* (4) has been stored on a majority of servers before committing the entries from prior terms. Because entries from term 4 have not been stored on a majority of the cluster, the entries at index 2 will not be committed and it's therefore safe for S5 to overwrite them. If the leader replicated an entry from its own term it could then commit the entries at index 2.

This is why commitment is not defined simply as an entry being stored on a majority of servers. To be committed, and entry must be stored on a majority of servers and the leader that commits it must have first replicated an entry from its own current term to a majority of the cluster. 

[Hui Kang]

Hi, Jordan

Thanks for you explanation, which makes the rule much more clear. I think your explanation should be included in the extended version of the raft paper : )

- Hui