In RAFT is it possible to have a majority consensus on a log entry but the entry is not committed?

[jltq...@gmail.com]

Consider this simulation screenshot in the official [raft webpage](https://raft.github.io/)

Why is `term 2 index 1` not committed despite `S2 (leader)` , `S3` and `S4` agreeing on the log? I run this multiple minutes to make sure all communication has taken place.

Weirdly enough, if I add one more log entry `term 6 index 2` then `term 2 index 1 ` will be committed.

Does anyone know what is the rule that is preventing `term 2 index 1` to be committed?

 

[Oren Eini (Ayende Rahien)]

Yes, that is possible.

The rule is that an entry can be committed only if an entry from the _current_ leader term has been confirmed to be on all nodes.

So if the leader in Term 2 has send entry C to all nodes but then there were elections, the entry C will not be committed until the new leader sent and confirmed the next entry in its term.

That is why the spec calls for a noop entry as part of the leader first action

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.

[jltq...@gmail.com]

Sorry if this is a beginner question, but why is this rule necessary? I am reading 5.4.2 from the raft paper and still don't understand why do we need to enforce this rule, since nodes without the latest index and term will never become a leader anyway?

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

[David B Murray]

> Sorry if this is a beginner question

Not at all.

> nodes without the latest index and term will never become a leader anyway.

It's very possible for a node without the latest index/term to become leader. This has happened in your screenshot: S2 is the leader even though S1, which is partitioned away, has an (uncommitted) log entry from term 4. This is fine: the rule is that the leader's log needs to contain all committed entries, which S2's does. And the alternative is waiting until you can reach all of the nodes to elect a leader, which has some hopefully-clear downsides. :)

Now, however, we've got a bit of a weird situation. S1 has the most up-to-date log, but its log disagrees with a majority of the cluster. If it becomes reachable again, S2, 3, and 4 would vote for it, and it could be elected leader even though its log is "wrong." If we want to declare term 2 index 1 committed, we need to be sure S1 won't be elected until it has fixed its log.

Different consensus algorithms handle this in different ways, as discussed in section 5.4.2. Raft's approach is characteristically simple -- just have S2 write a no-op into the log at term 6 index 2 when it gets elected. As soon as that gets successfully written on a majority of nodes, we no longer have to worry about S1 being elected and causing mischief, and we can safely call the entry at index 1 committed. If S1 reconnects, it will become a follower, realize its log is incorrect, and fix it.

-d

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

[jltq...@gmail.com]

Ah, that make alot of sense, now, thanks for the detail explanation.