[
https://issues.apache.org/jira/browse/HDDS-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781462#comment-16781462
]
Hanisha Koneru commented on HDDS-1175:
--------------------------------------
Patch v01 implements the following:
* OM caches the RaftPeerRole of its Ratis server.
* If OM leader receives a read request, it services the request directly from
RocksDB.
* If non leader OM receives a read request, it queries its ratis server to
find the current leader and returns this information to the client in the form
of NotLeaderException
* If client gets a NotLeaderException, it fails over to the suggested leader
and retries the request.
* On OM leader, we run a periodic role checked to verify its leader status.
* If a leader node's role changes to non leader role, the ratis server
notifies the OMStateMachine and this results in a failover to current leader.
> 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
> Reporter: Hanisha Koneru
> Assignee: Hanisha Koneru
> Priority: Major
> Attachments: HDDS-1175.001.patch
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
