-
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
Added support for new DDL actions for remove and add table partitioning #7822
Added support for new DDL actions for remove and add table partitioning #7822
Conversation
/run-all-tests |
@@ -219,6 +219,24 @@ void SchemaBuilder<Getter, NameMapper>::applyDiff(const SchemaDiff & diff) | |||
applyPartitionDiff(diff.schema_id, diff.table_id); | |||
break; | |||
} | |||
case SchemaActionType::ActionAlterTablePartitioning: | |||
{ | |||
if (diff.table_id == diff.old_table_id) |
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'm curious about that when diff.table_id = diff.old_table_id and when diff.table_id != diff.old_table_id, could you please give an example here?
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.
It is depending on the stage change, only the last (StateDeleteReorganization -> StatePublic) is the table ID changed to the new one.
Example (added custom logs):
tidb.log
[2023/08/01 23:11:59.568 +02:00] [WARN] [ddl_worker.go:1431] [updateSchemaVersion] [category=ddl] [TableId=96] [SchemaState="delete only"]
[2023/08/01 23:11:59.637 +02:00] [WARN] [ddl_worker.go:1431] [updateSchemaVersion] [category=ddl] [TableId=96] [SchemaState="delete only"]
[2023/08/01 23:11:59.702 +02:00] [WARN] [ddl_worker.go:1431] [updateSchemaVersion] [category=ddl] [TableId=96] [SchemaState="write only"]
[2023/08/01 23:11:59.798 +02:00] [WARN] [ddl_worker.go:1431] [updateSchemaVersion] [category=ddl] [TableId=96] [SchemaState="write reorganization"]
[2023/08/01 23:11:59.865 +02:00] [WARN] [ddl_worker.go:1431] [updateSchemaVersion] [category=ddl] [TableId=96] [SchemaState="delete reorganization"]
[2023/08/01 23:11:59.865 +02:00] [WARN] [ddl_worker.go:1441] [StateDeleteReorganization] [category=ddl] [TableId=105] [OldTableID=96]
tiflash.log
[2023/08/01 23:11:59.818 +02:00] [WARN] [SchemaBuilder.cpp:238] ["ActionRemovePartitioning table_id 96 old 96"] [source="keyspace=4294967295"] [thread_id=60]
[2023/08/01 23:11:59.819 +02:00] [WARN] [SchemaBuilder.cpp:238] ["ActionRemovePartitioning table_id 96 old 96"] [source="keyspace=4294967295"] [thread_id=60]
[2023/08/01 23:11:59.820 +02:00] [WARN] [SchemaBuilder.cpp:238] ["ActionRemovePartitioning table_id 96 old 96"] [source="keyspace=4294967295"] [thread_id=60]
[2023/08/01 23:11:59.821 +02:00] [WARN] [SchemaBuilder.cpp:238] ["ActionRemovePartitioning table_id 96 old 96"] [source="keyspace=4294967295"] [thread_id=60]
[2023/08/01 23:12:55.086 +02:00] [WARN] [SchemaBuilder.cpp:238] ["ActionRemovePartitioning table_id 105 old 96"] [source="keyspace=4294967295"] [thread_id=61]
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.
So in the first three stages, does the partition.definitions changes?
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 the first (StateNone->StateDeleteOnly), it adds the new partitions to TableInfo.Partition.AddingDefinitions and the removed ones to TableInfo.Partition.DroppingDefinitions.
In the second (StateDeleteOnly->StateWriteOnly), it only waits for the partitions to be available in TiFlash (if the table should have any TiFlash replicas).
In the third (StateWriteOnly->StateWriteReorganization), no changes or checks.
In the forth (StateWriteReorganization->StateDeleteReorganization), no changes (but does all the data copying and recreating the indexes).
In the fifth (StateDeleteReorganization->StatePublic), it depends on the actual command (reorganize, remove partitioning or alter table partition by):
- Reorganize, it will modify the TableInfo.Partition.Definitions by removing the DroppingDefinitions and add the AddingDefinitions and then reset AddingDefinitions and DroppingDefinitions.
- Remove partitioning, it will change the tableID to the one used for AddingDefinitions. Really drop the old partitioned table metadata, change the TableInfo by setting the table id to the single AddingDefinitions table id, and remove TableInfo.Partition, and then create the table (metadata) with the updated TableInfo.
- Alter Table Partition By, it will change the TableID and replace the TableInfo.Partition with the new partitioning type, expression and definitions. Also by first drop the table (metadata), change the TableInfo.Partition and table id, and the (re)create the table with the updated TableInfo.
Notice that the data cleanup is done later in an async way, and that the old table data also needs to be accessible during the schemaversion the DDL got during transitioning to StatePublic, since there may be clients in the schemaversion of StateDeleteReorganization that still need to read and (double) write the data.
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.
After some additional testing I figured out that I missed to drop the table (metadata) in TiFlash as well, not just create a new table :)
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
/run-all-tests |
/run-all-tests |
/run-all-tests |
/test-unit-test |
/run-all-tests |
The failing integration test |
/run-all-tests |
/run-all-tests |
blocked by pingcap/tidb#46645
|
@JaySon-Huang @mjonss Does it mean that some PR(which got merged recently) broke the CI of tiflash? |
|
||
func> wait_table test t | ||
|
||
mysql> set @@global.tidb_allow_mpp = 0; |
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.
mysql> set @@global.tidb_allow_mpp = 0; |
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.
Is tidb_allow_mpp = 0
necessary for your test cases? It will make the following tests fail.
I've pushed a commit to remove it for a try.
/run-all-tests |
/run-unit-test |
/run-integration-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hongyunyan, JaySon-Huang 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-integration-test |
1 similar comment
/run-integration-test |
What problem does this PR solve?
Issue Number: close #7823
Problem Summary:
ALTER TABLE t REMOVE PARTITIONING
and
ALTER TABLE t PARTITION BY ...
introduces new DDL Actions, which is not supported by TiFlash.
Handling those is the same as for other partitioning management DDLs, so it is easy to implement.
What is changed and how it works?
Check List
Tests
Side effects
Documentation
Release note