reset max_apply_unpersisted_log_limit in become_follower#561
Merged
Conversation
Contributor
Author
|
@Connor1996 @overvenus @gengliqi PTAL, thanks~ |
Connor1996
reviewed
Feb 20, 2025
Connor1996
left a comment
Connor1996
left a comment
Member
There was a problem hiding this comment.
Can we add a test to cover the case?
Signed-off-by: glorv <[email protected]>
glorv
force-pushed
the
reset-on-follower
branch
from
4247a6a to
09742ec
Compare
Signed-off-by: glorv <[email protected]>
glorv
force-pushed
the
reset-on-follower
branch
from
943a840 to
d5a0e2c
Compare
Merged
9 tasks
hhwyt
reviewed
Feb 21, 2025
| let from_role = self.state; | ||
| self.state = StateRole::Follower; | ||
| self.pending_request_snapshot = pending_request_snapshot; | ||
| // TODO: In theory, we should better control this in the caller, |
Signed-off-by: glorv <[email protected]>
Contributor
Author
|
@Connor1996 @hhwyt PTAL again |
Contributor
Author
|
@overvenus PTAL |
hbisheng
reviewed
Feb 24, 2025
Member
|
Would you mind putting down some context in the PR description? Otherwise it might not be obvious to future readers that this change is part of tikv/tikv#18241. |
Co-authored-by: Bisheng Huang <[email protected]> Signed-off-by: glorv <[email protected]>
overvenus
reviewed
Feb 25, 2025
| } | ||
|
|
||
| assert_eq!(sm.state, StateRole::Follower); | ||
| // check after become follower, the limit is reset. |
Member
There was a problem hiding this comment.
Please add some comments explaining why the reset is necessary.
Contributor
Author
There was a problem hiding this comment.
Done. PTAL again, thanks
Signed-off-by: glorv <[email protected]>
…to reset-on-follower
overvenus
reviewed
Feb 27, 2025
| // so we hard code this logic here currently. We may need to remove | ||
| // this hard code when we want to also support apply unpersisted log | ||
| // on follower. | ||
| self.raft_log.max_apply_unpersisted_log_limit = 0; |
Member
There was a problem hiding this comment.
Please update docs of this behavior change.
Signed-off-by: glorv <[email protected]>
overvenus
approved these changes
Feb 27, 2025
Signed-off-by: glorv <[email protected]>
Signed-off-by: glorv <[email protected]>
Signed-off-by: glorv <[email protected]>
glorv
force-pushed
the
reset-on-follower
branch
from
4d4157c to
8f0e01d
Compare
Member
|
/merge |
ti-chi-bot Bot
pushed a commit
to tikv/tikv
that referenced
this pull request
Feb 28, 2025
… from leader (#18241) ref #16717, close #17868 This PR adopt the changes in tikv/raft-rs#561 that directly reset the apply_unpersisted_log_limit limit in raft when leader is demoted. It fix the bug that in the previous impl, the reset is done in "on_role_change" which is called in handle_raft_ready, in the round that leader is demoted, it still return unpersisted comitted entries as at the time, the limit is not reset. NOTE: once we want to support this feature on follower, we need to remove the original assert as it is incorrect in this case. Signed-off-by: glorv <[email protected]>
ti-chi-bot Bot
pushed a commit
to tikv/tikv
that referenced
this pull request
Mar 4, 2025
… from leader (#18241) (#18260) ref #16717, close #17868 This PR adopt the changes in tikv/raft-rs#561 that directly reset the apply_unpersisted_log_limit limit in raft when leader is demoted. It fix the bug that in the previous impl, the reset is done in "on_role_change" which is called in handle_raft_ready, in the round that leader is demoted, it still return unpersisted comitted entries as at the time, the limit is not reset. NOTE: once we want to support this feature on follower, we need to remove the original assert as it is incorrect in this case. Signed-off-by: glorv <[email protected]> Co-authored-by: glorv <[email protected]>
ti-chi-bot Bot
pushed a commit
to tikv/tikv
that referenced
this pull request
Mar 4, 2025
… from leader (#18241) (#18261) ref #16717, close #17868 This PR adopt the changes in tikv/raft-rs#561 that directly reset the apply_unpersisted_log_limit limit in raft when leader is demoted. It fix the bug that in the previous impl, the reset is done in "on_role_change" which is called in handle_raft_ready, in the round that leader is demoted, it still return unpersisted comitted entries as at the time, the limit is not reset. NOTE: once we want to support this feature on follower, we need to remove the original assert as it is incorrect in this case. Signed-off-by: glorv <[email protected]> Co-authored-by: glorv <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR reset the
max_apply_unpersisted_log_limitvalue when peer role demote from leader to follower. Because the user can only notice role change event after callready()and the committed entries are collected in theready()so we have to do this here to ensure we only enablemax_apply_unpersisted_log_limiton raft leader.NOTE: In theory, the affect of
max_apply_unpersisted_log_limitis not related the raft role. We limit it to only leader to prevent potencial corn cases. We may want to remove this restriction in the future. In that case, we should revert this PR then.See tikv/tikv#17868 for more details.