[
https://issues.apache.org/jira/browse/RATIS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17278445#comment-17278445
]
runzhiwang edited comment on RATIS-1298 at 2/4/21, 1:02 AM:
------------------------------------------------------------
In our use, listener can also used as a standby, and never become follower,
unless an admin changes it. If all leader and follower crash and lost data, we
can use listener to recover the data, maybe we will lost some data in serveral
minutes, because listener lag behind leader, but it is acceptable. So in order
to make the system more strong, sometimes we need more than one listener.
bq. I would also argue that if we allow a follower join the Ratis ring but we
don't concern the performance
No, we concern the performance of follower join. For example, in HA case,
there is most "1 leader and 4 followers", we can not deploy "1 leader and 6
followers", because it will decrease the performance of cluster.
Then how can we achieve high availability same to "1 leader and 6 followers",
but use only "1 leader and 4 followers" ? We can achieve it by "1 leader and 4
followers and 2 learners", its high availability is similar to "1 leader and 6
followers", actually we allow all leader and followers crash, but has a better
performance.
bq. For etcd: https://etcd.io/docs/v3.3.12/learning/learner/. Seems that it
does not concern about catching up from leader in its practice.
The learner of etcd is mainly for membership change, not for high availability,
their learner will become follower when learner's log catch up. But we have a
different use case and behaviour.
Our design should not only support membership, but also support high
availability.
was (Author: yjxxtd):
In our use, listener can also used as a standby, and never become follower,
unless an admin changes it. If all leader and follower crash and lost data, we
can use listener to recover the data, maybe we will lost some data in serveral
minutes, because listener lag behind leader, but it is acceptable. So in order
to make the system more strong, sometimes we need more than one listener.
bq. I would also argue that if we allow a follower join the Ratis ring but we
don't concern the performance
No, we concern the performance of follower join. For example, in HA case,
there is most "1 leader and 4 followers", we can not deploy "1 leader and 6
followers", because it will decrease the performance of cluster.
Then how can we achieve high availability same to "1 leader and 6 followers",
but use only "1 leader and 4 followers" ? We can achieve it by "1 leader and 4
followers and 2 learners", its high availability is similar to "1 leader and 6
followers", actually we allow all leader and followers crash, but has a better
performance.
bq. For etcd: https://etcd.io/docs/v3.3.12/learning/learner/. Seems that it
does not concern about catching up from leader in its practice.
The learner of etcd is mainly for membership change, not for high availability,
their learner will become follower when learner's log catch up. But we have a
different use case and behaviour.
> Support non-voting members (Listeners/Learners)
> -----------------------------------------------
>
> Key: RATIS-1298
> URL: https://issues.apache.org/jira/browse/RATIS-1298
> Project: Ratis
> Issue Type: New Feature
> Components: server
> Reporter: Rui Wang
> Assignee: Rui Wang
> Priority: Major
>
> It's time to add the non-voting member, or leaner that is proposed in Raft
> thesis 4.2.1 (you can find a copy at [1]).
> The leaner is useful to maintain high availability when new servers join Raft
> ring (details at thesis 4.2.1). For Ozone SCM HA effort, we have also
> discussed the possibility to utilize leaner as the tool to replace SCM nodes
> online.
> [1]: https://github.com/ongardie/dissertation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
