raftstore: campaign newly created regions in time after Split#17625
raftstore: campaign newly created regions in time after Split#17625ti-chi-bot[bot] merged 38 commits intotikv:masterfrom
campaign newly created regions in time after Split#17625Conversation
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
|
Skipping CI for Draft Pull Request. |
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
|
/test pull-unit-test |
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
…ansfer leader. Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
Signed-off-by: lucasliang <nkcs_lykx@hotmail.com>
|
If Im right, the error is caused by:
So, the child region will wait election timeout. For this, why not just change the compain condition from leader to leader/candidate? |
|
Yep, this proposal is valid. However, we want to make "TransferLeader" and other operations which changes the So, this implementation enhance the checking of the |
@SpadeA-Tang I thinks there are 2 ways that a follower can become candidate: 1) transfer leader, 2) election timeout. So if the following became candidate due to election timeout and also apply split at the same time, the new created region should not start a election(and may become leader) because thus there may be two leader for the same region if the old leader does not finish executing the split command. |
It's not enough, peer 2 may already split before it receives MsgTimeoutNow. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Connor1996, hbisheng, overvenus, SpadeA-Tang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test all |
…kv#17625) close tikv#12410 This pr make the `campaign` of the newly splitted regions triggered in time, when the leadership of the parent region is stable after `on_role_changed`. Signed-off-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: ti-chi-bot[bot] <108142056+ti-chi-bot[bot]@users.noreply.github.com>
|
In response to a cherrypick label: new pull request created to branch |
close tikv#12410 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
…7625) (#17983) close #12410 This pr make the `campaign` of the newly splitted regions triggered in time, when the leadership of the parent region is stable after `on_role_changed`. Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Signed-off-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: lucasliang <nkcs_lykx@hotmail.com>
close tikv#12410 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
close tikv#12410 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
…7625) (#18148) close #12410 This pr make the `campaign` of the newly splitted regions triggered in time, when the leadership of the parent region is stable after `on_role_changed`. Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Signed-off-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: lucasliang <nkcs_lykx@hotmail.com>
…7625) (#17996) close #12410 This pr make the `campaign` of the newly splitted regions triggered in time, when the leadership of the parent region is stable after `on_role_changed`. Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Signed-off-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: ti-chi-bot[bot] <108142056+ti-chi-bot[bot]@users.noreply.github.com>
What is changed and how it works?
Issue Number: Close #12410 and #17602.
What's Changed:
As issues #12410 and #17602 shows, the original design of
CmdEpochCheckerallows theBatchSplitorSplitproposals even though the lastTransferLeaderis still on-going, making the newly created region cannotcampaignleader immediately. The root cause of these issues is thatTransferLeaderdoes not be recorded into the proposal queue inCmdEpochCheckeras it will not change theconf_ver, if the proposal queue has no conflicts admin commands.And these issues will damage the stability of TiKV, returning
9005errors to the Client who wanna access the relative data.So, to tackle these issues, this pr make the

campaignof the newly splitted regions triggered in time, when the leadership of the parent region is stable afteron_role_changed. And the newly added progress can be reviewed from the following diagram onstep 6.Related changes
pingcap/docs/pingcap/docs-cn:Check List
Tests
Side effects
Release note