[
https://issues.apache.org/jira/browse/RATIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz-wo Sze resolved RATIS-1262.
-------------------------------
Resolution: Duplicate
Resolving this as a duplicate of RATIS-1557.
> Support linearizable read
> -------------------------
>
> Key: RATIS-1262
> URL: https://issues.apache.org/jira/browse/RATIS-1262
> Project: Ratis
> Issue Type: New Feature
> Components: Linearizable Read
> Reporter: runzhiwang
> Assignee: runzhiwang
> Priority: Major
> Attachments: 截屏2020-12-24 下午3.31.32.png
>
>
> There are two case violate linearizable read, for example, there are 3
> servers: server1, server2, server3, and server1 is leader
> Case 1. server1: applyIndex = 2, commitIndex = 2, server2: applyIndex = 1,
> commitIndex = 2. When server1 step down, server2 become leader, and client
> read from server2,
> because server2's applyIndex less than commitIndex, client will read old data.
> Case 2. when split-brain happens, server2 was elected as new leader, but
> server1 still think it's leader, when client read from server1, if server2
> has processed write request, client will read old data from server1. As
> [~glengeng] explained, RATIS-981 still exist dirty-read in
> server.getMaxTimeoutMs(), i.e. 300ms, if split-brain happens.
> etcd / sofa-jraft / pingcap all support linearizable read which has been
> explained in raft paper, we can implement it in ratis. It's important in
> Ozone HA.
> pingcap's linearizable read: https://en.pingcap.com/blog/lease-read
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
