-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
copr: Split more accurately when buckey keys are not accurate. #34290
Conversation
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
[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. |
Please follow PR Title Format:
Or if the count of mainly changed packages are more than 3, use
After you have format title, you can leave a comment |
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/6912adb6ed4ae44bc12d43d55b093f480f6535a3 |
store/copr/region_cache.go
Outdated
// To easy the implementation of this function, we add region startKey if it is less than the first bucket key and add region endKey if | ||
// it is larger than the last bucket key. Without the addition, loc.LocateBucket may return nil which can cause troubles. | ||
if len(loc.Buckets.Keys) == 0 || bytes.Compare(loc.StartKey, loc.Buckets.Keys[0]) < 0 { | ||
loc.Buckets.Keys = append([][]byte{loc.StartKey}, loc.Buckets.Keys...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The content of the location should not be changed here, it's read-only in the original implementation. A possible option is to check the end_key
if LocateBucket
returns nil or changing the logic of LocateBucket
.
There's no mutable constraint in golang, be very careful if you decide to change the content of some input references.
res := []*LocationKeyRanges{} | ||
for ranges.Len() > 0 { | ||
bucket := loc.LocateBucket(ranges.At(0).StartKey) | ||
if bucket == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove the nil check, seems the loc.LocateBucket
could still return nil results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto, this should not be removed directly.
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
store/copr/region_cache.go
Outdated
if len(loc.Buckets.Keys) == 0 || (bytes.Compare(loc.StartKey, loc.Buckets.Keys[0]) < 0 || | ||
bytes.Compare(loc.Buckets.Keys[len(loc.Buckets.Keys)-1], loc.EndKey) < 0) { | ||
// If we need to modify the location, we copy and modify it. | ||
locCopy := *loc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may not use deep copy, it's necessary to use a clone or deep copy method if you want to deep copy or clone an object.
BTW, the bucket key meta has its specific meaning, it's better to change the split or task generation algorithm instead of changing meta info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could discuss the split and bucket task split algorithm and implementation with @youjiali1995 first I think.
res := []*LocationKeyRanges{} | ||
for ranges.Len() > 0 { | ||
bucket := loc.LocateBucket(ranges.At(0).StartKey) | ||
if bucket == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto, this should not be removed directly.
store/copr/region_cache.go
Outdated
func getKeyLocation(l *LocationKeyRanges) *tikv.KeyLocation { | ||
// Sometimes, there may be some delay between region information and buckets information within the region. | ||
// It may cause some gaps between the region startKey and first buckets key and region endKey and the last buckets key. | ||
// To easy the implementation of splitKeyRangeByBuckets, we copy the l.Location (with original value untouched) and add region startKey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To ease the implementation? Some tools like Grammarly could help reduce grammatical mistakes.
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
store/copr/coprocessor_test.go
Outdated
taskEqual(t, task, regionIDs[1], regionIDs[1], expectedTaskRanges[i]...) | ||
} | ||
|
||
// check edge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the difference between it and 'cover the whole region'?
@SpadeA-Tang |
store/copr/region_cache.go
Outdated
if i == ranges.Len() { | ||
res = append(res, &LocationKeyRanges{l.Location, ranges}) | ||
// ranges must be in loc.region, so the bucket returned by loc.LocateBucketV2 is guaranteed to be not nil | ||
bucket := loc.LocateBucketV2(ranges.At(0).StartKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the V2
mean? Do we need to use V1
somewhere else? If not we could remove the version in the name and try to avoid misunderstranding.
Signed-off-by: SpadeA-Tang <u6748471@anu.edu.au>
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 305c75a
|
/run-unit-test |
/run-mysql-test |
TiDB MergeCI notify🔴 Bad News! New failing [2] after this pr merged.
|
Signed-off-by: SpadeA-Tang u6748471@anu.edu.au
What problem does this PR solve?
Issue Number: close #34287
Problem Summary:
splitKeyRangesByBuckets
may not split tasks accurately when there are some disagreement between region and its bucket keys.For example, when we miss n and x in buckets which are the start and end of the region, we can inaccurately split the task ranges.
region: n------------------x
buckets: q---s---u
ranges: n--o p--s t--v w-x
Got: [n-o], [p-s], [t--u], [u-v, w-x]
Expected: [n-o, p-q], [q-s], [t--u], [u-v, w-x]
This PR fix this problem so that we can split the ranges as expected.
Related client-go changes:
tikv/client-go#486
tikv/client-go#497
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.