Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debug: add capability to "force" a load-based split #55116

Closed
tbg opened this issue Oct 1, 2020 · 3 comments
Closed

debug: add capability to "force" a load-based split #55116

tbg opened this issue Oct 1, 2020 · 3 comments
Labels
A-kv Anything in KV that doesn't belong in a more specific category. C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) good first issue no-issue-activity T-kv KV Team X-stale

Comments

@tbg
Copy link
Member

tbg commented Oct 1, 2020

Is your feature request related to a problem? Please describe.
When a user has a range that they wish to split to better distribute load (for example during a crisis situation), but load-based splitting does not do the job, the user has to manually construct a split key for use with ALTER TABLE ... SPLIT.

Describe the solution you'd like
Either via the UI or SQL, "force" a load-based split, meaning that the range will split based on the leader's best guess.

Describe alternatives you've considered
An alternative is to set the cluster setting that controls load-based split aggressiveness. However, this is a highly non-local solution that may cause many unrelated and possibly detrimental splits.

Jira issue: CRDB-3693

@tbg tbg added A-kv Anything in KV that doesn't belong in a more specific category. C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) labels Oct 1, 2020
@jlinder jlinder added the T-kv KV Team label Jun 16, 2021
@lunevalex
Copy link
Collaborator

@tbg I was thinking about the proposal and based on my observations from #72305 I think the best option would be to extend the ALTER RANGE syntax to support this, I think we can offer the following syntax to meet the proposed use cases ALTER RANGE 10 SPLIT and ALTER RANGE SPLIT FOR (SELECT range_id from crdb_internal_ranges where table_name = 'foo'

@ajwerner
Copy link
Contributor

A different approach to this problem is to move the thresholds for load-based splitting into zone/span configs. That's not to take anything away from the more precise statements @lunevalex is proposing. Both seem valuable. Increasingly, I think more and more KV allocator decisions should be configured on a per-span basis.

lunevalex added a commit to lunevalex/cockroach that referenced this issue Mar 16, 2022
Fixes cockroachdb#55116

Extend the ALTER RANGE syntax to support splitting a range.
ALTER RANGE x SPLIT will split a range at the best available
load based key. The new command will not perform a split directly
but rather advise the load based split decider to ignore the QPS
threshold and perform a load based split based on the lastest
available information. The decider has a 10s timeout built in between
deciding to split and determing the split key, so the actual split will
occur approximately 10s after the commnad is run.

To support all of this we changed AdminSplitRequest and added a new parameter
LoadBased. When set this will trigger a load based split on the range
through the split_queue.

Release note(sql change): Enhance the ALTER RANGE syntax to
allow an operator to manually perform a load based split of
a range.
lunevalex added a commit to lunevalex/cockroach that referenced this issue Jun 13, 2022
Fixes cockroachdb#55116

Extend the ALTER RANGE syntax to support splitting a range.
ALTER RANGE x SPLIT will split a range at the best available
load based key. The new command will not perform a split directly
but rather advise the load based split decider to ignore the QPS
threshold and perform a load based split based on the lastest
available information. The decider has a 10s timeout built in between
deciding to split and determing the split key, so the actual split will
occur approximately 10s after the commnad is run.

To support all of this we changed AdminSplitRequest and added a new parameter
LoadBased. When set this will trigger a load based split on the range
through the split_queue.

Release note(sql change): Enhance the ALTER RANGE syntax to
allow an operator to manually perform a load based split of
a range.
lunevalex added a commit to lunevalex/cockroach that referenced this issue Jun 14, 2022
Fixes cockroachdb#55116

Extend the ALTER RANGE syntax to support splitting a range.
ALTER RANGE x SPLIT will split a range at the best available
load based key. The new command will not perform a split directly
but rather advise the load based split decider to ignore the QPS
threshold and perform a load based split based on the lastest
available information. The decider has a 10s timeout built in between
deciding to split and determing the split key, so the actual split will
occur approximately 10s after the commnad is run.

To support all of this we changed AdminSplitRequest and added a new parameter
LoadBased. When set this will trigger a load based split on the range
through the split_queue.

Release note(sql change): Enhance the ALTER RANGE syntax to
allow an operator to manually perform a load based split of
a range.
lunevalex added a commit to lunevalex/cockroach that referenced this issue Sep 27, 2022
Fixes cockroachdb#55116

Extend the ALTER RANGE syntax to support splitting a range.
ALTER RANGE x SPLIT will split a range at the best available
load based key. The new command will not perform a split directly
but rather advise the load based split decider to ignore the QPS
threshold and perform a load based split based on the lastest
available information. The decider has a 10s timeout built in between
deciding to split and determing the split key, so the actual split will
occur approximately 10s after the commnad is run.

To support all of this we changed AdminSplitRequest and added a new parameter
LoadBased. When set this will trigger a load based split on the range
through the split_queue.

Release note(sql change): Enhance the ALTER RANGE syntax to
allow an operator to manually perform a load based split of
a range.
lunevalex added a commit to lunevalex/cockroach that referenced this issue Oct 3, 2022
Fixes cockroachdb#55116

Extend the ALTER RANGE syntax to support splitting a range.
ALTER RANGE x SPLIT will split a range at the best available
load based key. The new command will not perform a split directly
but rather advise the load based split decider to ignore the QPS
threshold and perform a load based split based on the lastest
available information. The decider has a 10s timeout built in between
deciding to split and determing the split key, so the actual split will
occur approximately 10s after the commnad is run.

To support all of this we changed AdminSplitRequest and added a new parameter
LoadBased. When set this will trigger a load based split on the range
through the split_queue.

Release note(sql change): Enhance the ALTER RANGE syntax to
allow an operator to manually perform a load based split of
a range.
@github-actions
Copy link

github-actions bot commented Sep 6, 2023

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 18, 2023
@github-project-automation github-project-automation bot moved this to Closed in KV Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-kv Anything in KV that doesn't belong in a more specific category. C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) good first issue no-issue-activity T-kv KV Team X-stale
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants