-
Notifications
You must be signed in to change notification settings - Fork 411
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 unstable DROP TABLE
/FLASHBACK TABLE
/RECOVER TABLE
(#8422)
#8444
ddl: Fix unstable DROP TABLE
/FLASHBACK TABLE
/RECOVER TABLE
(#8422)
#8444
Conversation
29b9533
to
4637b12
Compare
/run-all-tests |
Signed-off-by: JaySon-Huang <tshent@qq.com>
/run-all-tests |
/run-all-tests |
1 similar comment
/run-all-tests |
/run-integration-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JaySon-Huang, Lloyd-Pottiger The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
/run-all-tests |
This is an automated cherry-pick of #8422
What problem does this PR solve?
Issue Number: close #8395, close #1664, close #3777
Problem Summary:
Problem 1:
There could be a chance that raft snapshot or raft command of a table comes after it has been dropped.
Because tiflash will ignore the previous
DROP TABLE
, because storage instance is not created yet. The storage instance is created as "non tombstone" after that when raft snapshot or raft command comes. And the storage instance will never be physically dropped until tiflash restarts.Problem 2:
In the second time when
syncTableSchema
callstrySyncTableSchema
after table-id-mapping is up-to-date, it should usemvcc get
to ensure it can use the table schema of tombstone table to create Storage instance or decode new raft logs, or some new columns data will not be decoded.Previously
updateTiFlashReplica
will update the table info with the latest columns by accident. So tiflash pass the related tests sometimes.What is changed and how it works?
This is a PR following #8421
The logic changes is these commits: https://github.com/pingcap/tiflash/pull/8422/files/d88f6b6f4ae4c8026b969cd9c5ae50924b179529..1fe991997055f755aea89cd2e2bdb8ab26a848bf
syncTableSchema
callstrySyncTableSchema
, it will not usemvcc get
so that we can detect whether we need to update the table-id-mappingsyncTableSchema
callstrySyncTableSchema
after table-id-mapping is up-to-date, it will usemvcc get
to ensure it can use the table schema of tombstone table to create Storage instance or decode new raft logs.SchemaGetter::getTableInfoImpl
does not check the existence ofdb_key
, so that we can still get the table info after database is dropped. (get ready forFLASHBACK DATABASE ... TO ...
)client-c mvcc get
, then we will create the storage instance with a tombstone timestamp. So that it can be physically dropped after GC time.applySetTiFlashReplica
should only update the tiflash replica info instead of replacing all the table info, or it will lead to some later DDLs (changing partitions, etc) is not executedrecover table
codes using early returnCheck List
Tests
Side effects
Documentation
Release note