[
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.
I am talking about linearizability read.
h1. Background && Motivation
Linearizability read is a very friendly feature for developers, kudu can
support it. Now I find kudu may be implements yet.
h1. Issue of linearizability read from leader
We need talk about the issue.
The feture is especially important for kv system, and kudu is mainly olap
oriented. But in some scenaios, the feature also privide advantages.
Kudu's read implements by Scan, event though read one row. It send a
ScanRequest with NewScanRequest and then send ContinueScanRequest. The feature
will be aimed at NewScanRequest.
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:
!image-2022-07-20-23-17-40-718.png!
# 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.
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.
h1. Solution
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:
The next 3 days, I'll fix the idea of the issue. After make sure the problem,
Maybe I should provide a document for the issue.
As describe as https://issues.apache.org/jira/browse/KUDU-3382.
h1. Background && Motivation
Linearizability read is a very friendly feature for developers, kudu can
support it. Now I find kudu may be implements yet.
h1. Issue of linearizability read from leader
We need talk about the issue.
The feture is especially important for kv system, and kudu is mainly olap
oriented. But in some scenaios, the feature also privide advantages.
Kudu's read implements by Scan, event though read one row. It send a
ScanRequest with NewScanRequest and then send ContinueScanRequest. The feature
will be aimed at NewScanRequest.
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:
!image-2022-07-20-23-17-40-718.png!
# 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.
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.
h1. Solution
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.
> 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
> Assignee: shenxingwuying
> Priority: Major
> Attachments: image-2022-07-20-23-14-34-519.png,
> image-2022-07-20-23-17-40-718.png
>
>
> As describe as https://issues.apache.org/jira/browse/KUDU-3382.
> I am talking about linearizability read.
> h1. Background && Motivation
> Linearizability read is a very friendly feature for developers, kudu can
> support it. Now I find kudu may be implements yet.
> h1. Issue of linearizability read from leader
> We need talk about the issue.
> The feture is especially important for kv system, and kudu is mainly olap
> oriented. But in some scenaios, the feature also privide advantages.
> Kudu's read implements by Scan, event though read one row. It send a
> ScanRequest with NewScanRequest and then send ContinueScanRequest. The
> feature will be aimed at NewScanRequest.
> 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:
>
> !image-2022-07-20-23-17-40-718.png!
>
> # 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.
> 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.
> h1. Solution
> 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)
