scheduler: compatibility about query info in hot scheduler #3947
Conversation
Signed-off-by: lhy1024 <admin@liudos.us>
|
[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. Reviewer can indicate their review by submitting an approval review. |
|
/rebuild |
Codecov Report
@@ Coverage Diff @@
## master #3947 +/- ##
==========================================
+ Coverage 74.65% 74.71% +0.05%
==========================================
Files 246 246
Lines 25094 25117 +23
==========================================
+ Hits 18734 18765 +31
+ Misses 4701 4699 -2
+ Partials 1659 1653 -6
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Is it enough to explain in the documentation? |
Signed-off-by: lhy1024 <admin@liudos.us>
Signed-off-by: lhy1024 <admin@liudos.us>
Signed-off-by: lhy1024 <admin@liudos.us>
Signed-off-by: lhy1024 <admin@liudos.us>
| } | ||
|
|
||
| bs.isSelectedDim = func(dim int) bool { | ||
| return dim == bs.firstPriority || dim == bs.secondPriority | ||
| } | ||
| } | ||
|
|
||
| // adjustConfig will adjust config for cluster with low version tikv | ||
| // because tikv below 5.2.0 does not report query information, we will use byte and key as the scheduling dimensions | ||
| func (bs *balanceSolver) adjustConfig(origins, defaults []string) (first, second int) { |
There was a problem hiding this comment.
Should we check the length of origins?
There was a problem hiding this comment.
I will do it in another pr
Signed-off-by: lhy1024 <admin@liudos.us>
|
/merge |
|
@lhy1024: It seems you want to merge this PR, I will help you trigger all the tests: /run-all-tests Instructions 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. Commit hash: fef1820
|
What problem does this PR solve?
Low versions of tikv do not have qps statistics, so when using a low version of tikv with a high version of pd, the hotspot scheduling will not be as expected
What is changed and how it works?
For upgrading from versions before 5.2 to 5.2, regardless of the read priorities and write priorities, pd will schedule hotspots according to byte and key priorities until all tikv's in the cluster have been upgraded.
Check List
Tests
Release note