raftstore: Introduce force leader state#11932
Conversation
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
|
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. DetailsReviewer can indicate their review by submitting an approval review. |
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
|
PTAL too @v01dstar |
v01dstar
left a comment
There was a problem hiding this comment.
Losing leadership in election timeout while check_quorum = true should be taken into consideration?
Yes, do you want to add an API to change that? If not, I'll do it. |
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
|
I think there is a remaining problem about the learner role with the force leader mechanism, see #6107 (comment) |
Good point. Adding a test to see if the learner can call |
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Add a case to force the learner to be the leader. Seems no problem, as we can promote it to be a voter once in force leader state. |
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
It may more than just whether a learner can become leader, I worry about what may happen after a learner became leader as we always assume that only voter can become leader. /cc @BusyJay |
991d573 to
720ed5b
Compare
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
| .raft_group | ||
| .raft | ||
| .prs() | ||
| .has_quorum(&expected_alive_voter) |
There was a problem hiding this comment.
Supposing (a, b, c, d, e) -> (a, b, c, d, f) -> (a, b, c, g, f), and a, b, g, f all fail. c is isolated during the whole time. It may think it still has quorum (c, d, e).
There was a problem hiding this comment.
Emmm.... In this case, force leader can't be performed as well, as we add pre-force-leader check expecting all votes from expected alive voters
There was a problem hiding this comment.
Indeed. Perhaps what we should do is check if there is rejection instead of expecting all approvals.
There was a problem hiding this comment.
The logic of forwarding the commit index also has the same issue. I'd like to leverage the mechanism introduced by this PR #7636 to filter the peers.
It's an extreme corner case, I'd record an issue now and fix it after the whole procedure is workable.
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
Signed-off-by: Connor1996 <zbk602423539@gmail.com>
|
/merge |
|
@Connor1996: It seems you want to merge this PR, I will help you trigger all the tests: /run-all-tests You only need to trigger If you have any questions about the PR merge process, please refer to pr process. 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 ti-community-infra/tichi repository. |
|
This pull request has been accepted and is ready to merge. DetailsCommit hash: cd6f7f2 |
|
/test |
close tikv#6107, ref tikv#10483 Signed-off-by: Connor1996 <zbk602423539@gmail.com>
close tikv#6107, ref tikv#10483 Signed-off-by: Connor1996 <zbk602423539@gmail.com>
* raftstore: Introduce force leader state (tikv#11932) close tikv#6107, ref tikv#10483 Signed-off-by: Connor1996 <zbk602423539@gmail.com> * raftstore: Wait ticks for hibernated peer when doing force leader (tikv#12364) ref tikv#10483 Force leader is rejected on a peer who is already a leader. For the hibernated leader, it doesn't step down to follower when quorum is missing due to not ticking election. So wait ticks in force leader process for hibernated peers to make sure election ticking is performed. Signed-off-by: Connor1996 <zbk602423539@gmail.com> Co-authored-by: Ti Chi Robot <ti-community-prow-bot@tidb.io> * raftstore: Make unsafe recovery wait apply cover snapshot apply cases ref tikv#10483 (tikv#12308) ref tikv#10483 Signed-off-by: v01dstar <yang.zhang@pingcap.com> * raftstore: Execute recovery plan via raft (tikv#12022) Signed-off-by: Connor1996 <zbk602423539@gmail.com> Co-authored-by: Ti Chi Robot <ti-community-prow-bot@tidb.io> Co-authored-by: Yang Zhang <yang.zhang@pingcap.com>
What is changed and how it works?
Issue Number: Close #6107
What's Changed:
Part of #10483, Introduce force leader state to advance commit index even if the quorum is not formed. This is used for online unsafe recover.
Related changes
pingcap/docs/pingcap/docs-cn:pingcap/tidb-ansible:Check List
Tests
Release note