-
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
ddl: fix admin repair table will reload fail on the other node (#18285) #18323
ddl: fix admin repair table will reload fail on the other node (#18285) #18323
Conversation
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
/run-all-tests |
infoschema/builder.go
Outdated
@@ -74,7 +74,17 @@ func (b *Builder) ApplyDiff(m *meta.Meta, diff *model.SchemaDiff) ([]int64, erro | |||
// We try to reuse the old allocator, so the cached auto ID can be reused. | |||
var allocs autoid.Allocators | |||
if tableIDIsValid(oldTableID) { | |||
<<<<<<< HEAD |
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.
Fix conflicts
Signed-off-by: AilinKid <314806019@qq.com>
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
@djshow832,Thanks for your review. |
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
@zimulala,Thanks for your review. |
/run-all-tests |
/run-all-tests |
cherry-pick #18285 to release-4.0
What problem does this PR solve?
Problem Summary:
Now in TiDB cluster, if config one node as repair-mode node, the other node could not reload the new schema info after the table has been repaired.
The reason is because
repair-node: information schema has filtered the repaired tables, so for itself, apply the create table logic is ok.
other-node: information schema has included the repaired tables, so for them, should apply the drop table first, then create new table.
Root cause:
sortedTablesBuckets will append the new repaired table into it, when find table with
TableByID
, then binary search will get the first old one rather the new one with same table ID (so should drop it first)What is changed and how it works?
How it Works: drop old table first when apply repaired table in
applydiff
Related changes
Check List
Tests
Release note