Re: [raft-dev] Question Regarding Log Consistencies

26 views
Skip to first unread message

Archie Cobbs

unread,
Jun 25, 2024, 10:04:20 AM (10 days ago) Jun 25
to raft...@googlegroups.com
On Tue, Jun 25, 2024 at 2:40 AM Daniel Shin <kyuseu...@gmail.com> wrote:
Lets say B's timer ends the fastest, B increments its term by 1 (term 1 now) and becomes leader (which is possible because C and D are also term 1)

C and D have already voted for E as leader in term 1, therefore they may not later also vote for B for term 1. That would be voter fraud :)

-Archie

--
Archie L. Cobbs

Milan Savic

unread,
Jun 25, 2024, 2:08:35 PM (10 days ago) Jun 25
to raft...@googlegroups.com
Hi Daniel, 

It is not possible that B gets elected. C and D have a leader for term 1 - E, so they wouldn't vote for node B. In other words, only nodes C and D are eligible to become the next leader.

Cheers,
Milan


On Tue, Jun 25, 2024, 9:40 AM Daniel Shin <kyuseu...@gmail.com> wrote:
Hello!

I had a quick question on how Raft is able to enforce log consistency, ie: Log Matching Property: when the term and log number of two nodes match, then the contents of the log should match.

If we consider to have 5 nodes, A, B, C, D, E

If they start at roughly the same time, so, they all start with term 0.

Lets suppose E gets elected, with votes ONLY from C, D, and A, B are dead,
So, currently, in persistent state, A, B are term 0, C, D, E is term 1 with E as leader.

Lets say E appends an entry to its own log and dies, failing to replicate.

All this happens very quick, and C, D has their election timers reset.

A, B comes back alive --> they are still term 0. C, D have no log entries, but they are term 1.

Lets say B's timer ends the fastest, B increments its term by 1 (term 1 now) and becomes leader (which is possible because C and D are also term 1)

B replicates a log to A, C, D --> term 1, log 1 (because all of them don't have any other logs)

Node E comes alive. At this point, E has term 1 log 1, but with a different log value...?

I'm pretty sure that this is a rudimentary question, but I couldn't really find answers online. 

Best Regards,

Daniel

--
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/abbcd60e-bd69-431a-8eec-48a6d84e4550n%40googlegroups.com.

Vilho Raatikka

unread,
Jun 25, 2024, 2:08:41 PM (10 days ago) Jun 25
to raft...@googlegroups.com
Hi, the next Leader will operate on term 2 not 1. As a consequence the first operation is [2,1] (term, index), which doesn't conflict with E.

When B sends voting requests it applies its term (=0)  but it won't be elected before it has first upgraded its term to the same level as that of the majority.

Regards

Vilho

Daniel Shin

unread,
Jun 25, 2024, 7:59:34 PM (9 days ago) Jun 25
to raft-dev
Yup my bad, thank you for the clarification! 

Will it be safe to assume that the persistent state votedFor is reset to (none, empty string, etc) whenever a node updates its term because of an RPC request/response?

Reply all
Reply to author
Forward
0 new messages