[
https://issues.apache.org/jira/browse/HDDS-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Viswanadham updated HDDS-4484:
-------------------------------------
Description:
Previously RatisServer which is network-partitoned/split-brain does not step
down from leader state, so we require custom logic to determine leader(But that
is also not completely correct, as the role state is updated based on server
state not a quorum based information)
Now, in Ratis leader steps down after the leader election max time out, so we
can use RaftServer Api isLeader check. (RATIS-981 fixed this behavior)
This also fixes when serving read requests it should check leaderReady, not
just isLeader because when it is leader, it might be still applying pending
commit transactions, so there is a chance that acked transactions of write,
might not be visible until we wait for isLeaderReady.
was:
Previously RatisServer which is network-partitoned/split-brain does not step
down from leader state, so we require custom logic to determine leader(But that
is also not completely correct, as the role state is updated based on server
state not a quorum based information)
Now, in Ratis leader steps down after the leader election max time out, so we
can use RaftServer Api isLeader check. (RATIS-981 fixed this behavior)
> Use RatisServerImpl isLeader instead of periodic leader update logic in OM
> --------------------------------------------------------------------------
>
> Key: HDDS-4484
> URL: https://issues.apache.org/jira/browse/HDDS-4484
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
>
> Previously RatisServer which is network-partitoned/split-brain does not step
> down from leader state, so we require custom logic to determine leader(But
> that is also not completely correct, as the role state is updated based on
> server state not a quorum based information)
> Now, in Ratis leader steps down after the leader election max time out, so we
> can use RaftServer Api isLeader check. (RATIS-981 fixed this behavior)
> This also fixes when serving read requests it should check leaderReady, not
> just isLeader because when it is leader, it might be still applying pending
> commit transactions, so there is a chance that acked transactions of write,
> might not be visible until we wait for isLeaderReady.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
