Re: [raft-dev] Question about replicating log with safety

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

S1 can still _replicate_ entries from prior terms, it just can't _commit_ them. In other words, S1 can't increase commitIndex after it's elected unless its to an index in its term. That's the only constraint here. So, when S1 is elected, it replicates the entry from term 2 like any other entry, but it can't commit it once it's been stored on a majority of the cluster. Only once it has replicated an entry from term 4 can it increase its commitIndex and update followers.

On Aug 17, 2017, at 12:57 AM, Injun Song <ijs...@gmail.com> wrote:

Hi all,

I have a question about log replicating and safety:

Let's assume that S1 is elected after (b). But unlike (c), S1 tries to replicate an entry with term 4 (maybe it is no-op entry) to avoid leader completeness violation (5.4.2 in the paper).

According to log replication, S1 has to handle inconsistencies of followers. To do that, S1 should match its nextIndex with followers'.

If S5 is still failed, and only S3 and S4 have only the first entry (term=1 and index=1), how can S1 commit the no-op entry with the current term 4?

Thank you.

Best regards,

Injun Song

--
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.
For more options, visit https://groups.google.com/d/optout.

[Injun Song]

Hi Jordan,

I appreciate your kind reply. I got it.

Thank you again.

Best regards,

Injun Song