[
https://issues.apache.org/jira/browse/RATIS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175139#comment-17175139
]
runzhiwang edited comment on RATIS-967 at 8/11/20, 1:38 AM:
------------------------------------------------------------
[~szetszwo] Thanks for review.
1. I agree by "preferred leader", we can achieve balanced leader distribution
in ozone multi-raft. I have two questions.
For example, s1, s2, s3 make a raft group, and s1 is the "preferred leader".
1.1 How can we implement "preferred leader" ?
I think we can start a background thread: tryGetLeaderThread in
s1, tryGetLeaderThread check whether s1 is the leader periodicity, if not, s1
will trigger a
leader election to get the leader.
1.2 What we can do when the "preferred leader" is not preferred any more ?
After a long time, s1 will not be the preferred leader any more,
for example it's network IO become slow, and follower timeout happen too
frequent.
What we can do, destroy the raft group and create a new one ? It
maybe too expensive to do this.
2. Even though we have "preferred leader", maybe we still need "transferring
leadership".
The following paragraph copied from raft paper, can be happen in ozone OM/SCM
HA. And some raft projects have implemented "transferring leadership" to
address this, such as etcd, tikv, sofa-jraft.
"For example, it may need to reboot for maintenance, or it may be removed from
the cluster (see Chapter 4).
When it steps down, the cluster will be idle for an election timeout until
another server times out and wins an election.
This brief unavailability can be avoided by having the leader transfer its
leadership to another server before it steps down."
was (Author: yjxxtd):
[~szetszwo] Thanks for review.
h1. 1. I agree by "preferred leader", we can achieve balanced leader
distribution in ozone multi-raft. I have two questions.
For example, s1, s2, s3 make a raft group, and s1 is the "preferred leader".
1.1 How can we implement "preferred leader" ?
I think we can start a background thread: tryGetLeaderThread in
s1, tryGetLeaderThread check whether s1 is the leader periodicity, if not, s1
will trigger a
leader election to get the leader.
1.2 What we can do when the "preferred leader" is not preferred any more ?
After a long time, s1 will not be the preferred leader any more,
for example it's network IO become slow, and follower timeout happen too
frequent.
What we can do, destroy the raft group and create a new one ? It
maybe too expensive to do this.
2. Even though we have "preferred leader", maybe we still need "transferring
leadership".
The following paragraph copied from raft paper, can be happen in ozone OM/SCM
HA. And some raft projects have implemented "transferring leadership" to
address this, such as etcd, tikv, sofa-jraft.
"For example, it may need to reboot for maintenance, or it may be removed from
the cluster (see Chapter 4).
When it steps down, the cluster will be idle for an election timeout until
another server times out and wins an election.
This brief unavailability can be avoided by having the leader transfer its
leadership to another server before it steps down."
> Transfer leadership from leader to follower
> -------------------------------------------
>
> Key: RATIS-967
> URL: https://issues.apache.org/jira/browse/RATIS-967
> Project: Ratis
> Issue Type: Sub-task
> Components: raft-group
> Affects Versions: 0.5.0
> Reporter: maobaolong
> Assignee: runzhiwang
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With this api, we can transition leader state to a specify one for datanodes
> in the same pipeline, OM group and SCM group.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
