[
https://issues.apache.org/jira/browse/HDDS-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260134#comment-17260134
]
runzhiwang commented on HDDS-1175:
----------------------------------
bq. Many other systems have used a notion of "Leader Lease" to avoid this
problem. I have been thinking another way to solve this issue is to read from
any 2 nodes, and if they value of the key does not agree, we can use the later
version of the key.
[~aengineer] [~hanishakoneru] [~bharat] I'm working on "Leader Lease" on
RATIS-1273.
But even though we make sure current OM is leader, there still exist dirty read.
For example, 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.
So I'm also working on "Support linearizable read" on RATIS-1262
> Serve read requests directly from RocksDB
> -----------------------------------------
>
> Key: HDDS-1175
> URL: https://issues.apache.org/jira/browse/HDDS-1175
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Components: OM HA, Ozone Manager
> Reporter: Hanisha Koneru
> Assignee: Hanisha Koneru
> Priority: Major
> Labels: pull-request-available
> Attachments: HDDS-1175.001.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We can directly server read requests from the OM's RocksDB instead of going
> through the Ratis server. OM should first check its role and only if it is
> the leader can it server read requests.
> There can be a scenario where an OM can lose its Leader status but not know
> about the new election in the ring. This OM could server stale reads for the
> duration of the heartbeat timeout but this should be acceptable (similar to
> how Standby Namenode could possibly server stale reads till it figures out
> the new status).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]