Drainer Fails to Start After Converting Partitioned Table to Regular Table

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 分区表转普通表后drainer无法启动

| username: TiDBer_a3wWH0G2

[TiDB Usage Environment] Production Environment
[TiDB Version] 6.5.1
[Reproduction Path] Operations performed that led to the issue:
Changed partition table to normal table, executed partition exchange, and rename table operations.
ALTER TABLE fulfillorder_part EXCHANGE PARTITION p2023 WITH TABLE fulfillorder_2023;
rename table order_fulfill_data.fulfillorder_2023 to order_fulfill_data.fulfillorder;
[Encountered Issue: Problem Phenomenon and Impact]
After restarting drainer, the following message appears:
[2023/11/17 23:44:29.544 +08:00] [INFO] [schema.go:550] [“Finished dropping column”] [job=“ID:168947, Type:drop column, State:synced, SchemaState:none, SchemaID:167106, TableID:167998, RowCount:0, ArgLen:0, start time: 2023-05-11 15:09:37.05 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0”]
[2023/11/17 23:44:29.544 +08:00] [INFO] [schema.go:550] [“Finished dropping column”] [job=“ID:168948, Type:drop column, State:synced, SchemaState:none, SchemaID:167106, TableID:167998, RowCount:0, ArgLen:0, start time: 2023-05-11 15:09:38.1 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0”]
[2023/11/17 23:44:29.544 +08:00] [INFO] [schema.go:550] [“Finished dropping column”] [job=“ID:168949, Type:drop column, State:synced, SchemaState:none, SchemaID:167106, TableID:167998, RowCount:0, ArgLen:0, start time: 2023-05-11 15:09:39.151 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0”]
[2023/11/17 23:44:29.580 +08:00] [ERROR] [server.go:292] [“syncer exited abnormal”] [error="handlePreviousDDLJobIfNeed failed: handle ddl job ID:189151, Type:rename table, State:synced, SchemaState:public, SchemaID:188443, TableID:188451, RowCount:0, ArgLen:0, start time: 2023-11-17 21:32:27.219 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0 failed, the schema info: {\n\t\t"hasImplicitCol": false,\n\t\t"schemaMetaVersion": 0,\n\t\t"schemaNameToID": {\n\t\t\t"atom-sign-all": 3664,\n\t\t\t"auction_data": 181330,\n\t\t\t"cubeweb_by": 51,\n\t\t\t"daas": 121,\n\t\t\t"daas_crs_portal": 16521,\n\t\t\t"daas_customer":

| username: dba远航 | Original post link

This is not a conversion failure; it should be an issue with the rename.

| username: Hacker_ZcrkjsVg | Original post link

Is there any way to make the drainer skip? All downstream drainers are not working.

| username: 小龙虾爱大龙虾 | Original post link

Please refer to: TiDB Binlog 常见问题 | PingCAP 文档中心

| username: TiDBer_a3wWH0G2 | Original post link

I don’t think it’s an issue with the downstream. These errored drainers have filters and shouldn’t be executing these DDL statements. Additionally, the downstream is also TiDB, so there shouldn’t be any compatibility issues.

In this error, there’s no TS, so it can’t be skipped.

| username: TiDBer_a3wWH0G2 | Original post link

Look at the error message
[errorVerbose="table(188451) or its schema not found

But actually, when checking in TiDB, this table does exist

| username: Raymond | Original post link

The fundamental reason is that drainer does not support partition exchange at all. You can simulate it to see for yourself. If you encounter a partition exchange situation, you can only use PITR to replace drainer.

| username: TiDBer_a3wWH0G2 | Original post link

Is there any way to fix this?
Now the drainer can’t start, and rebuilding it doesn’t work either.

| username: 小龙虾爱大龙虾 | Original post link

The reason it won’t start is because the drainer reads all historical DDLs when it starts. Please upgrade the drainer separately (via patch) to version 6.5.3 or above and then try to start it again, as version 6.5.3 has improved the way DDLs are fetched. See drainer/schema: replace drainer's schema with ticdc's schema storage · Issue #1137 · pingcap/tidb-binlog · GitHub. After the upgrade, the drainer will load DDLs in a manner similar to ticdc, which should bypass unsupported DDLs.

| username: Raymond | Original post link

Drainer does not support partition exchange.

| username: Raymond | Original post link

If you can ensure that partition exchange will not be used in the future, you can try the method mentioned above to see if you can skip the historical DDL. However, if partition exchange will still be used in the future, this issue will still be encountered.