[jira] [Updated] (KUDU-3383) About strong consistency read from leader

["shenxingwuying (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

shenxingwuying updated KUDU-3383:
---------------------------------
    Description: 
As describe as https://issues.apache.org/jira/browse/KUDU-3382.

 

 
h1. Background && Motivation

Linearizability read is a very friendly for developers, kudu can support it.
h1. Issue of linearizability read from leader

We need talk about the issue.

Kudu's raft implements is a strong leader, leader's state machine is not older than followers, and followers heartbeat timeout or receives leader election request(leader transfer) can elect leader and switch leader.

If kudu need linearizability read, read leader is not enough, because double leader may be exist at a very small period time.

I provide two scenarios. The first one:

 

{{L1(1)----F2(1)            L(1)   F2(2)|                             /
|           --->            /F3(1)                     L3(2)}}
 # A raft group has 3 replicas, L1, F2, F3. Their states is steady during term 1.
 # If network parition, F2 and F3 loss leader's heartbeat, F3 start election, F2 vote it.
 # F3 become Leader, we can call it L3. At this moment, there are 2 leaders: L1(1) and L3(2).
 # The state will be continued until the network partition recover. The time may be short or long.

During double leader, it's not liearizability read. So kudu should avoid double leader at any time, pay the corresponding cost is no leader at a small period time. Kudu should make a choice. For user usally need linearizability, so I think kudu should support it. During a very small time no leader's unavailability can avoid by client's fault tolerance.

Whether read leader is linearizability read, someone can make sure it or I can do a experiment.

 

{{L(1)----F(1)            L(1)   F(2)|                             /
|           --->            /F(1)                    L(2)}}
h1. Solution

kudu should avoid double leaders at a very small period time and network fault happens . I review the codes, and think now the problem is exist.

To avoid the double leader's trouble，leader should be keep alive. If a leader receives no enough heartbeats in a period of time, it shoud be leader down and and then start another election just like follower does. Leader's timeout should be less than follower's election.

Another scheme: Read should send heartbeat to two follow to make sure it is valid leader.

  was:
As describe as https://issues.apache.org/jira/browse/KUDU-3382.

 

 

TO BE CONTINUE


> About strong consistency read from leader
> -----------------------------------------
>
>                 Key: KUDU-3383
>                 URL: https://issues.apache.org/jira/browse/KUDU-3383
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: shenxingwuying
>            Priority: Major
>
> As describe as https://issues.apache.org/jira/browse/KUDU-3382.
>  
>  
> h1. Background && Motivation
> Linearizability read is a very friendly for developers, kudu can support it.
> h1. Issue of linearizability read from leader
> We need talk about the issue.
> Kudu's raft implements is a strong leader, leader's state machine is not older than followers, and followers heartbeat timeout or receives leader election request(leader transfer) can elect leader and switch leader.
> If kudu need linearizability read, read leader is not enough, because double leader may be exist at a very small period time.
> I provide two scenarios. The first one:
>  
> {{L1(1)----F2(1)            L(1)   F2(2)|                             /
> |           --->            /F3(1)                     L3(2)}}
>  # A raft group has 3 replicas, L1, F2, F3. Their states is steady during term 1.
>  # If network parition, F2 and F3 loss leader's heartbeat, F3 start election, F2 vote it.
>  # F3 become Leader, we can call it L3. At this moment, there are 2 leaders: L1(1) and L3(2).
>  # The state will be continued until the network partition recover. The time may be short or long.
> During double leader, it's not liearizability read. So kudu should avoid double leader at any time, pay the corresponding cost is no leader at a small period time. Kudu should make a choice. For user usally need linearizability, so I think kudu should support it. During a very small time no leader's unavailability can avoid by client's fault tolerance.
> Whether read leader is linearizability read, someone can make sure it or I can do a experiment.
>  
> {{L(1)----F(1)            L(1)   F(2)|                             /
> |           --->            /F(1)                    L(2)}}
> h1. Solution
> kudu should avoid double leaders at a very small period time and network fault happens . I review the codes, and think now the problem is exist.
> To avoid the double leader's trouble，leader should be keep alive. If a leader receives no enough heartbeats in a period of time, it shoud be leader down and and then start another election just like follower does. Leader's timeout should be less than follower's election.
> Another scheme: Read should send heartbeat to two follow to make sure it is valid leader.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)