[
https://issues.apache.org/jira/browse/RATIS-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678527#comment-17678527
]
Kaijie Chen edited comment on RATIS-1762 at 1/19/23 7:44 AM:
-------------------------------------------------------------
{quote}For RATIS-1770, if the higher priority peer lags behind a lot, it may
take some time to catch up the latest transaction. If the prior leader reject
client requests, then the service may be unavailable for a long time.
{quote}
To solve this problem, we should probably introduce a non-blocking
TransferLeadership (which don't block client request).
||TransferLeadership||Requested by||Blocks client request?||Has a timeout?||Can
be aborted?||
|Blocking (current)|Client (shell)|Yes|Yes|No|
|Non-blocking (new)|Priority checking|No|No|Yes, by another blocking or
non-blocking TransferLeadership|
was (Author: ckj996):
{quote}For RATIS-1770, if the higher priority peer lags behind a lot, it may
take some time to catch up the latest transaction. If the prior leader reject
client requests, then the service may be unavailable for a long time.
{quote}
To solve this problem, we should probably introduce a non-blocking
TransferLeadership (which don't block client request).
||TransferLeadership||Requested by||Blocks client request?||Has a timeout?||Can
be aborted?||
|Blocking (current)|Client (shell)|Yes|Yes|No|
|Non-blocking (new)|Priority checking|No|No|Yes, by another blocking or
non-blocking request|
> Support transfer leadership between nodes with same priority
> ------------------------------------------------------------
>
> Key: RATIS-1762
> URL: https://issues.apache.org/jira/browse/RATIS-1762
> Project: Ratis
> Issue Type: Sub-task
> Reporter: Kaijie Chen
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current transfer leadership implementation in Ratis is depending on priority.
> The current leader will periodically check follower's priority, and yield
> leader to higher priority peer.
> In this Jira, I propose to implement the basic transfer leadership operation,
> which is described in section 3.10 "leadership transfer extension" of [Diego
> Ongaro's PhD
> dissertation|https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf].
> In a future Jira, we can change the current
> "yieldLeaderToHigherPriorityPeer()" to use this operation.
> Steps of the transfer leadership operation:
> # The prior leader stops accepting new client requests.
> # The prior leader fully updates the target server’s log to match its own,
> using the normal log replication mechanism.
> # The prior leader sends a TimeoutNow request to the target server. This
> request has the same effect as the target server’s election timer firing: the
> target server starts a new election (incrementing its term and becoming a
> candidate).
> Success condition:
> * Once the target server receives the TimeoutNow request, it is highly
> likely to start an election before any other server and become leader in the
> next term. Its next message to the prior leader will include its new term
> number, causing the prior leader to step down. At this point, leadership
> transfer is complete.
> Failure condition:
> * It is also possible for the target server to fail; in this case, the
> cluster must resume client operations. If leadership transfer does not
> complete after about an election timeout, the prior leader aborts the
> transfer and resumes accepting client requests. If the prior leader was
> mistaken and the target server is actually operational, then at worst this
> mistake will result in an extra election, after which client operations will
> be restored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
