-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
infoschema: maintain the snapshotTS in the infocache #25322
Conversation
e8341ef
to
f3d4560
Compare
68d656a
to
5469654
Compare
5469654
to
ebdc91a
Compare
Why not add an extra cache of I did not like |
/rebuid |
@xhebox Actually already has |
/run-all-tests |
1 similar comment
/run-all-tests |
/run-integration-common-test |
e903766
to
906a966
Compare
Signed-off-by: nolouch <[email protected]>
906a966
to
5b41099
Compare
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.
Need a TestGetBySnapshotTS
to cover all branches, but I could send a PR for that if you want to merge the PR first.
Rest LGTM.
Signed-off-by: nolouch <[email protected]>
Signed-off-by: nolouch <[email protected]>
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.
LGTM
@JmPotato: Thanks for your review. The bot only counts approvals from reviewers and higher roles in list, but you're still welcome to leave your comments. In response to this:
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. |
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.
func (do *Domain) GetSnapshotInfoSchema(snapshotTS uint64) (infoschema.InfoSchema, error) { | ||
// if the snapshotTS is new enough, we can get infoschema directly through sanpshotTS. | ||
if is := do.infoCache.GetBySnapshotTS(snapshotTS); is != nil { | ||
return is, 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.
I think this may cause the infoschema inconsistency in following case.
1. infoschema cache holding `t1` as maxUpdatedSnapshotTS and infoschema for `schema version` v1
2. ddl worker running ddl job with `t2` in txn and increased `schema version` to v2 while infoschema cache have not been awared of this changing yet.
3. load infoschema with snapshotTS t3 (t3 > t2 > t1) and using infoschema with v1 schema version.
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.
Infocache
is used everywhere, it is promised to sync the latest infoschema for the current tidb instance(not necessarily the latest for all tidb instances, actually ddl owner tidb can not immediately get the latest, too).
And of course, there are edge cases. It is indeed not a 100% consistent method. But it is also impossible to avoid kvget
by promising 100% consistency.
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.
In my example, I think we don't need to guarantee that the query must use the schema version v2's infoschema if the changing is not related to the tables we visit.
But I think the following checking is ncessary:
- check whether there exists any schema version changed bewtween
t1
(maxUpdatedSnapshotTS) andt3
(snapshotTS) - If exists, check whether the changing is related to the table we vistied.
- If related, reloading the infoschema with
t3
snapshotTS to use the right infoschema.
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.
In my example, I think we don't need to guarantee that the query must use the schema version v2's infoschema if the changing is not related to the tables we visit.
But I think the following checking is necessary:
- check whether there exists any schema version changed bewtween
t1
(maxUpdatedSnapshotTS) andt3
(snapshotTS) - If exists, check whether the changing is related to the table we vistied.
- If related, reloading the infoschema with
t3
snapshotTS to use the right infoschema.
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.
lgtm
[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. |
/merge |
@Yisaer: In response to this:
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. |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: fd16fb0
|
/run-common-test |
/run-all-tests |
Signed-off-by: ti-srebot <[email protected]>
cherry pick to release-5.1 in PR #25376 |
Signed-off-by: nolouch [email protected]
What problem does this PR solve?
Issue Number: #25303
Problem Summary:
Infoschema cache is introduced by #24285, which mainly used for stale read and history read. It let executor can get the corresponding history schema. But even if we have the cache, every request still needs to go to TiKV to obtain the schema version to confirm the corresponding schema. which leads one TiKV to have many
KV_Get
, This may let one TiKV who has the meta region's leader consume too much CPU and become a bottleneck. And intuitively, the request is unbalanced:What is changed and how it works?
sanpshotTS
, which is the oldest ts we have used with the schema.Infoschema
directly with the specified timestamp.Check List
Tests
Release note