Re: [raft-dev] unsafety about leader transfer operation

48 views
Skip to first unread message

Jordan Halterman

unread,
Dec 11, 2017, 7:21:47 PM12/11/17
to raft...@googlegroups.com
I'm not exactly sure what you're referring to. Can you reference the exact section of the dissertation?

Section 3.10 describing the leadership transfer extension doesn't describe a protocol that transfers leadership without communicating with a majority of the cluster. It describes one where the current leader replicates all its existing entries to a follower, then the leader forces the follower's election to time out. From that point forward, the normal leader election protocol is used to safely elect a new leader. The fact that the normal election protocol is used to transfer leadership to the new node should mean that it has the same properties as we see in normal leader elections.

On Mon, Dec 11, 2017 at 6:41 AM, jin deng <cheney...@gmail.com> wrote:
hi all,
    The phd version of the raft paper supplies a leader transfer operation which need NOT communicate with majority members to be a leader.I think this will break the rule that: only one leader will be elected during the same term.

    Imagine we have 5 nodes and there is a network split between two parts: one with 2 nodes and the other with 3.The old leader leaves in the minority part and transfer its leadership to the other node within the same part.At the same time the majority part begins a election and finally elected a new leader.The two leader will have same term and what's more,the leader lease may not be able to detect this situation because the lease has not expired.So we may get stale read on the old leader.

    Is this a weakness of the leadership transfer mechanism?maybe we can solve this problem by forcing to make sure the election timeout time is more than leader lease timeout,but that impose a requirement about time correctness which is raft avoid.

--
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.

jin deng

unread,
Dec 11, 2017, 9:19:20 PM12/11/17
to raft-dev


在 2017年12月12日星期二 UTC+8上午8:21:47,Jordan Halterman (kuujo)写道:
I'm not exactly sure what you're referring to. Can you reference the exact section of the dissertation?

Section 3.10 describing the leadership transfer extension doesn't describe a protocol that transfers leadership without communicating with a majority of the cluster. It describes one where the current leader replicates all its existing entries to a follower, then the leader forces the follower's election to time out. From that point forward, the normal leader election protocol is used to safely elect a new leader. The fact that the normal election protocol is used to transfer leadership to the new node should mean that it has the same properties as we see in normal leader elections.

you are right,I misunderstand its behavior :-).It does have e effective election. 
Reply all
Reply to author
Forward
0 new messages