log-backup: Keep the order of observation IDs consistent with the order in which they were received (#18290)#18980
Conversation
Signed-off-by: Jianjun Liao <jianjun.liao@outlook.com>
Signed-off-by: Jianjun Liao <jianjun.liao@outlook.com>
Signed-off-by: Jianjun Liao <jianjun.liao@outlook.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
This cherry pick PR is for a release branch and has not yet been approved by triage owners. To merge this cherry pick:
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@ti-chi-bot: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This is an automated cherry-pick of #18290
What is changed and how it works?
Issue Number: Close #18243
What's Changed:
Additional notes
There are always three observe operations (Stop[Pre-Candidate], Stop[Candidate] and Start[Leader]) generated when any peer becomes leader. But the observe operation
Start[Leader]may lost due to no task registered yet. Besides, when a log backup task is being registered, the endpoint will send a observe operationStart[Scanned]for a leader.Case 1: If the observe operation
Start[Leader]is ignored because the task is not registered yet.We can make sure the endpoint must get the region when a new task is being registered. We have the following execution order:
In this case, the step 2 is already done, so we can make sure that the region update query is already in the queue of
region_info_accessor.schedulerwhen the endpoint sendsRegionInfoQuery::SeekRegionto theregion_info_accessor. Therefore, the endpoint can get the region fromseek_region.Case2: If the endpoint can not get the region from
seek_region.We can make sure the observe operation
Start[Leader]is not ignored. We have the following execution order:In this case, the step 2 is already done, so we can make sure that the task range is registered. Therefore, the step 4 is not ignored and the observe operation
Start[Leader]is scheduled.In summary, the
region_operatormay meet theStart[Scanned] -> Stop[Pre-Candidate] -> Stop[Candidate] -> Start[Leader]and repeat scanning the region. But it won't lost the region if it is leader.Related changes
pingcap/docs/pingcap/docs-cn:Check List
Tests
Side effects
Release note