Confusion about "committing entries from previous terms"

[tianyu chen]

In the paper 《 In Search of an Understandable Consensus Algorithm 》, Figure 8 shows a problem in (d) and (e) that some old logs may be overwritten and never come back. 

In section 5.4.2, it says “To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas. 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”.

I'm confused about that part, how does it works in Figure 8? What will happen and what will not?

[Jordan Halterman]

With the restriction in 5.4.2, the scenarios depicted in Figure 8 can all still happen. A leader could replicate an entry to a majority of the cluster only for it to be overwritten by a newer leader. But what’s important is that the leader does not consider an entry that’s merely been replicated to a majority of nodes to be committed. An entry *in its current term* must be replicated to a majority of nodes before it can consider entries from prior terms committed. This ensures the leader will not e.g. apply entries to its state machine or respond to a client indicating some entry was committed which could be later overwritten. So, it’s just an important restriction on what the leader considers committed but doesn’t necessarily affect the scenarios depicted in Figure 8.

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/bc5f9c37-db07-49f4-91c0-5c9912edfe22%40googlegroups.com.

[keanue li]

that means restriction in 5.4.2 just make us know  what leader should commit . it does not  solve the scenarios depicted in Figure 8?

thanks.

[Soham Dongargaonkar]

The scenario in figure 8 isn't something we can solve or avoid.

The scenario basically explains why a leader cannot commit an entry from a previous term UNTIL AND UNLESS there is a newer entry in the current term that has been replicated. Once there is a newer entry in the current term and it is replicated successfully, the entry from the previous term is "safe" since it can now never get overwritten, and thus Raft can go ahead and commit it.

From an implementation point of view, nothing needs to be done since the code that commits entries and say, sends them on a channel, will "walk" through the logs it has and commit each and every log up until the log from the current term. This will make sure that the logs from the earlier terms are committed only when there is a newer log with the current term that is also ready to be committed.

Raft is... genius!