作者： Raymond
一、测试背景
最近在笔者个人的测试环境中突然发现一个drainer节点宕机了，且无法拉起，通过查看drainer的日志的关键字
table xxx not found，于是笔者猜测这应该和tidb节点的ddl变更有关系，于是看了下ddl的变更历史记录发现是对某个表做了交换分区的处理，难道是drainer 不兼容交换分区功能导致？通过查阅官方文档https://docs.pingcap.com/zh/tidb/v6.5/basic-features#分区 发现交换分区是在6.5的版本中正式引入的，恰巧笔者的环境也是6.5.3，所以笔者猜测还真有可能是交换分区导致的，于是带着这个好奇心重新测试了下，在这里简单说明下交换分区的作用，交换分区的作用是交换分区和非分区表，类似于rename table,具体的说明可以查阅官方文档https://docs.pingcap.com/zh/tidb/v6.5/partitioned-table#分区管理
二、测试过程
测试版本:v6.5.3
测试过程:
1.新建1个分区表e
表结构来源于
https://dev.mysql.com/doc/refman/8.0/en/partitioning-management-exchange.html
CREATE TABLE e (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30)
)
PARTITION BY RANGE (id) (
PARTITION p0 VALUES LESS THAN (50),
PARTITION p1 VALUES LESS THAN (100),
PARTITION p2 VALUES LESS THAN (150),
PARTITION p3 VALUES LESS THAN (MAXVALUE)
);
查询该表的table id 为93,然后查询每个分区的分区id
mysql> select * from information_schema.tables where table_name = 'e'\G
*************************** 1. row ***************************
TABLE_CATALOG: def
TABLE_SCHEMA: test
TABLE_NAME: e
TABLE_TYPE: BASE TABLE
ENGINE: InnoDB
VERSION: 10
ROW_FORMAT: Compact
TABLE_ROWS: 4
AVG_ROW_LENGTH: 19
DATA_LENGTH: 77
MAX_DATA_LENGTH: 0
INDEX_LENGTH: 0
DATA_FREE: 0
AUTO_INCREMENT: NULL
CREATE_TIME: 2023-09-03 10:27:19
UPDATE_TIME: NULL
CHECK_TIME: NULL
TABLE_COLLATION: utf8mb4_bin
CHECKSUM: NULL
CREATE_OPTIONS: partitioned
TABLE_COMMENT:
TIDB_TABLE_ID: 93
TIDB_ROW_ID_SHARDING_INFO: NOT_SHARDED
TIDB_PK_TYPE: NONCLUSTERED
TIDB_PLACEMENT_POLICY_NAME: NULL
1 row in set (0.00 sec)
mysql> select * from information_schema.PARTITIONS where TABLE_NAME ='e'\G
*************************** 1. row ***************************
TABLE_CATALOG: def
TABLE_SCHEMA: test
TABLE_NAME: e
PARTITION_NAME: p0
SUBPARTITION_NAME: NULL
PARTITION_ORDINAL_POSITION: 1
SUBPARTITION_ORDINAL_POSITION: NULL
PARTITION_METHOD: RANGE
SUBPARTITION_METHOD: NULL
PARTITION_EXPRESSION: `id`
SUBPARTITION_EXPRESSION: NULL
PARTITION_DESCRIPTION: 50
TABLE_ROWS: 1
AVG_ROW_LENGTH: 20
DATA_LENGTH: 20
MAX_DATA_LENGTH: 0
INDEX_LENGTH: 0
DATA_FREE: 0
CREATE_TIME: 2023-09-03 10:27:19
UPDATE_TIME: NULL
CHECK_TIME: NULL
CHECKSUM: NULL
PARTITION_COMMENT:
NODEGROUP: NULL
TABLESPACE_NAME: NULL
TIDB_PARTITION_ID: 94
TIDB_PLACEMENT_POLICY_NAME: NULL
由此可知e表p0分区的id为94
2.新建1个非分区表e2
CREATE TABLE e2 (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30)
);
mysql> select * from information_schema.tables where table_name = 'e2'\G
*************************** 1. row ***************************
TABLE_CATALOG: def
TABLE_SCHEMA: test
TABLE_NAME: e2
TABLE_TYPE: BASE TABLE
ENGINE: InnoDB
VERSION: 10
ROW_FORMAT: Compact
TABLE_ROWS: 0
AVG_ROW_LENGTH: 0
DATA_LENGTH: 0
MAX_DATA_LENGTH: 0
INDEX_LENGTH: 0
DATA_FREE: 0
AUTO_INCREMENT: NULL
CREATE_TIME: 2023-09-03 10:32:47
UPDATE_TIME: NULL
CHECK_TIME: NULL
TABLE_COLLATION: utf8mb4_bin
CHECKSUM: NULL
CREATE_OPTIONS:
TABLE_COMMENT:
TIDB_TABLE_ID: 105
TIDB_ROW_ID_SHARDING_INFO: NOT_SHARDED
TIDB_PK_TYPE: NONCLUSTERED
TIDB_PLACEMENT_POLICY_NAME: NULL
1 row in set (0.01 sec)
由此可知e2的table id为105
3.分区表与非分区表进行交换
INSERT INTO e VALUES
(1669, "Jim", "Smith"),
(337, "Mary", "Jones"),
(16, "Frank", "White"),
(2005, "Linda", "Black");
mysql> select * from e;
+------+-------+-------+
| id | fname | lname |
+------+-------+-------+
| 1669 | Jim | Smith |
| 337 | Mary | Jones |
| 2005 | Linda | Black |
| 1669 | Jim | Smith |
| 337 | Mary | Jones |
| 2005 | Linda | Black |
| 16 | Frank | White |
| 16 | Frank | White |
+------+-------+-------+
8 rows in set, 1 warning (0.05 sec)
ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2;
将e表的p0分区的数据交换到e2表
mysql> select * from e2;
+----+-------+-------+
| id | fname | lname |
+----+-------+-------+
| 16 | Frank | White |
| 16 | Frank | White |
+----+-------+-------+
2 rows in set (0.00 sec)
mysql> select * from e;
+------+-------+-------+
| id | fname | lname |
+------+-------+-------+
| 1669 | Jim | Smith |
| 337 | Mary | Jones |
| 2005 | Linda | Black |
| 1669 | Jim | Smith |
| 337 | Mary | Jones |
| 2005 | Linda | Black |
+------+-------+-------+
6 rows in set, 1 warning (0.01 sec)
由此可知，交换分区成功
4.交换后table id发生的变化
mysql> select * from information_schema.tables where table_name = 'e2'\G
*************************** 1. row ***************************
TABLE_CATALOG: def
TABLE_SCHEMA: test
TABLE_NAME: e2
TABLE_TYPE: BASE TABLE
ENGINE: InnoDB
VERSION: 10
ROW_FORMAT: Compact
TABLE_ROWS: 2
AVG_ROW_LENGTH: 20
DATA_LENGTH: 40
MAX_DATA_LENGTH: 0
INDEX_LENGTH: 0
DATA_FREE: 0
AUTO_INCREMENT: NULL
CREATE_TIME: 2023-09-03 10:38:24
UPDATE_TIME: NULL
CHECK_TIME: NULL
TABLE_COLLATION: utf8mb4_bin
CHECKSUM: NULL
CREATE_OPTIONS:
TABLE_COMMENT:
TIDB_TABLE_ID: 94
TIDB_ROW_ID_SHARDING_INFO: NOT_SHARDED
TIDB_PK_TYPE: NONCLUSTERED
TIDB_PLACEMENT_POLICY_NAME: NULL
1 row in set (0.00 sec)
mysql> select * from information_schema.PARTITIONS where TABLE_NAME ='e'\G
*************************** 1. row ***************************
TABLE_CATALOG: def
TABLE_SCHEMA: test
TABLE_NAME: e
PARTITION_NAME: p0
SUBPARTITION_NAME: NULL
PARTITION_ORDINAL_POSITION: 1
SUBPARTITION_ORDINAL_POSITION: NULL
PARTITION_METHOD: RANGE
SUBPARTITION_METHOD: NULL
PARTITION_EXPRESSION: `id`
SUBPARTITION_EXPRESSION: NULL
PARTITION_DESCRIPTION: 50
TABLE_ROWS: 0
AVG_ROW_LENGTH: 0
DATA_LENGTH: 0
MAX_DATA_LENGTH: 0
INDEX_LENGTH: 0
DATA_FREE: 0
CREATE_TIME: 2023-09-03 10:27:19
UPDATE_TIME: NULL
CHECK_TIME: NULL
CHECKSUM: NULL
PARTITION_COMMENT:
NODEGROUP: NULL
TABLESPACE_NAME: NULL
TIDB_PARTITION_ID: 105
TIDB_PLACEMENT_POLICY_NAME: NULL
由此可知，交换分区后,e2的table id变成了原来e表p0分区的table id 94,而e表p0分区的tidb_partition_id 变成了原来e2表的
105，也就是分区交换后，table id也进行了互换
三、测试结果
那么进行分区交换后导致的tabld id 也发生了变化会带来什么后果呢？当对e2进行一个ddl时，比如说删除e2表
drop table e2;那么drainer 是否可以正常处理这个ddl，通过查看的drainer.log,可以看到drainer 已经开始报错了，而报错的原因是因为table 94 not found,这也是就是drainer 暂时无法支持这种如果表是交换分区后产生的特殊处理，而且会导致drainer进程无法正常运行
[2023/09/03 10:41:04.223 +08:00] [ERROR] [main.go:69] ["start drainer server failed"] [error="handle ddl job ID:108, Type:drop table, State:synced, SchemaState:none, SchemaID:85, TableID:94, RowCount:0, ArgLen:0, start time: 2023-09-03 10:41:02.807 +0800 CST, Err:<nil>, ErrCount:0, SnapshotVersion:0 failed, the schema info: xxxx
table 94 not found"]
四、结论
通过以上的测试我们可以得出目前drainer组件其实是不兼容交换分区的处理，所以在日常的使用过程中我们要注意这点，在官方没有完善drainer的这个兼容性后，如果应用层面无法避免使用交换分区的逻辑，那么在TiDB层面应该使用br log来代替drainer的使用 https://docs.pingcap.com/zh/tidb/v6.5/br-pitr-guide。
