You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "runzhiwang (Jira)" <ji...@apache.org> on 2020/08/11 01:39:00 UTC
[jira] [Comment Edited] (RATIS-967) Transfer leadership from leader
to follower
[ 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)