[
https://issues.apache.org/jira/browse/RATIS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279487#comment-17279487
]
runzhiwang edited comment on RATIS-1298 at 2/5/21, 9:09 AM:
------------------------------------------------------------
[~szetszwo] I have a design of listener, could you help review it ?
*Structure*
listeners can get log from followers or listeners, but can not get log from
leader. The structure of leader, followers ,listeners as follows:
!screenshot-1.png!
*Raft Group*
Listeners do not need to join the raft group, listeners can register themselves
to followers or listeners.
*Do not change to follower automatically*
Listeners will not change to follower automatically, but we can use admin
command to change listener to follower.
*Push Or Pull*
Follower or listener push log to listener. With push we can reuse the current
code of LogAppender.
*Only Push committed log*
We only append the committed log to listeners, otherwise listeners need to
truncate log which was truncated by the leader.
*How to register*
When we start a listener, we pass a list of upstream servers to it, which need
to be persisted. Upstream servers can contain: leader, follower, listener.
Then the new listener send request to the list of upstream servers to ask their
information, then the new listener choose which upstream server to register
according to:
1. How many listeners the upstream server has registered, each upstream server
can only container N listeners.
2. Whether the upstream server is leader, leader can not register listener
3. The depth of the upstream server, because we can register listener to
listener. If we register the new listener to another listener with a deep
depth, the new listener needs a long time to catch up with leader's state. The
new listener register to the upstream server, which is not leader, and has
minimum depth, and has less than N registered listeners.
*Kick off Listener *
The upstream server will kick of listener if:
1. Upstream server become leader
2. The heartbeat to listener timeout, upstream server will send heartbeat to
listener with low frequency.
3. Admin command
*Listener re-choose upstream server*
The listener will re-choose upstream server if:
1. Can not receive heartbeat.
2. Admin command reset the list of upstream server.
was (Author: yjxxtd):
[~szetszwo] I have a design of listener, could you help review it ?
*Structure*
listener can get log from followers or listeners, but can not get log from
leader. The structure of leader, followers ,listeners as follows:
!screenshot-1.png!
*Raft Group*
Listeners do not need to join the raft group, listeners can register themselves
to followers or listeners.
*Do not change to follower automatically*
Listeners will not change to follower automatically, but we can use admin
command to change listener to follower.
*Push Or Pull*
Follower or listener push log to listener. With push we can reuse the current
code of LogAppender.
*Only Push committed log*
We only append the committed log to listeners, otherwise listeners need to
truncate log which was truncated by the leader.
*How to register*
When we start a listener, we pass a list of upstream servers to it, which need
to be persisted. Upstream servers can contain: leader, follower, listener.
Then the new listener send request to the list of upstream servers to ask their
information, then the new listener choose which upstream server to register
according to:
1. How many listeners the upstream server has registered, each upstream server
can only container N listeners.
2. Whether the upstream server is leader, leader can not register listener
3. The depth of the upstream server, because we can register listener to
listener. If we register the new listener to another listener with a deep
depth, the new listener needs a long time to catch up with leader's state. The
new listener register to the upstream server, which is not leader, and has
minimum depth, and has less than N registered listeners.
*Kick off Listener *
The upstream server will kick of listener if:
1. Upstream server become leader
2. The heartbeat to listener timeout, upstream server will send heartbeat to
listener with low frequency.
3. Admin command
*Listener re-choose upstream server*
The listener will re-choose upstream server if:
1. Can not receive heartbeat.
2. Admin command reset the list of upstream server.
> 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
> Attachments: screenshot-1.png
>
>
> 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)
