release-21.1: kvserver: get rid of bespoke relocation logic used by the mergeQueue #62762
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.
Backport 3/3 commits from #62631.
/cc @cockroachdb/release
This PR contains two main commits:
kvserver: update
AdminRelocateRange
to leverage explicit swaps ofvoters to non-voters
This commit updates
AdminRelocateRange
to use explicit atomic swaps ofvoting replicas with non-voting replicas, that #58627 initially added
support for. The patch does so by generalizing behavior that's already
exercised by the
replicateQueue
when it decides to rebalance replicas.See #61239.
This allows us, in the next commit, to remove bespoke relocation logic
that's used by the
mergeQueue
to align replica sets for the sake of arange merge.
Release note: None
kvserver: get rid of bespoke relocation logic used by the mergeQueue
This commit removes the relocation logic used by the
mergeQueue
thusfar to align replica sets (added in #56197). This logic previously
existed in order to allow us to align the replica sets of a pair of
ranges (which is required for the range merge to proceed), while
avoiding redundant data movement.
Before #58627 and the previous commit in this PR,
AdminRelocateRange
couldn't be directly used by the mergeQueue under various configurations
of the LHS and RHS ranges. Furthermore, even when it could be used, it
would involve redundant data movement. This all required us to compute
relocation targets for the RHS of a merge separately, above the call to
AdminRelocateRange
, for the range merge to proceed.All these limitations have been resolved by the previous commit which
teaches
AdminRelocateRange
to promote non-voters and demote voterswhen needed, and the aforementioned bespoke relocation logic is no
longer needed.
Resolves #62370
Release note: None