单表数据迁移到备份表要怎么做

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境
【TiDB 版本】8.1.0
【部署方式】腾讯云
【操作系统/CPU 架构/芯片详情】X86
【机器部署详情】16C32G 1T
【集群数据量】900G
【集群节点数】3PD 3KV
【遇到的问题：问题现象及影响】整个库有个比较大的单表，按天分区，现在有340+个分区了，数据量在9亿条，400G左右，现在需要把半年前的数据挪到同库的一摸一样的备份表，试过了br，没办法直接恢复到备份表，目前AI给的方案是用Dumpling + Lightning 直接从原表导出，考虑到单表数据量很大，而且是生产库，想请教下这个方案可行性和需要注意的点，或者是有别的更好的办法，感谢。

2

我们的话，会使用三方etl工具，比如kettle，按分区逐个来迁移。

3

kettle 支持表名路由嘛

4

介绍个工具datax

5

需要手工指定原表和目标表，简单说就是写个 insert into xxx select xxx，区别是kettle可以多线程插入，比写insert快。

6

exchange不知道是否符合要求。如果只能使用Dumpling+Lightning的方式，就是验证好线程数以及速度避免影响生产吧。导出导入的用户价格RU限制？
EXCHANGE PARTITION 语句用来交换分区和非分区表，类似于重命名表如 RENAME TABLE t1 TO t1_tmp, t2 TO t1, t1_tmp TO t2 的操作。

例如，ALTER TABLE partitioned_table EXCHANGE PARTITION p1 WITH TABLE non_partitioned_table 交换的是 p1 分区的 partitioned_table 表和 non_partitioned_table 表。

7

https://docs.pingcap.com/zh/tidb/stable/partitioned-table/

EXCHANGE PARTITION:语句用来交换分区和非分区表，类似于重命名表如 RENAME TABLE t1 TO t1_tmp, t2 TO t1, t1_tmp TO t2 的操作。

ALTER TABLE partitioned_table EXCHANGE PARTITION p1 WITH TABLE non_partitioned_table;

交换的是 p1 分区的 partitioned_table 表和 non_partitioned_table 表。

如果备份也是分区表，上面的操作执行2次：

    1. 生产的历史分区 to tmp
    1. tmp to 备份表的历史分区

注意事项：交换分区后，要及时收集生产表的统计信息，检查全局索引的有效性。

8

1、迁移避开业务高峰期
2、使用etl工具，比如datax，分区处理，优先处理几个测试下效率，然后批次迁移，不建议一次性操作，不然会给集群比较大的压力

9

目前想法是从生产库BR数据下来放到测试库，然后从测试库按分区Dumpling数据下来Lightning到生产备份表，这样可行吗

10

备份表还是需要分区的，还要作为冷数据库给应用层查询，exchange我看写法with non_partition_table，交换过去之后就没有分区了吗

11

就是不知道从生产BR下来的数据能不能恢复到测试库，一样的库名和表名

12

分库分表迁移注意全局唯一ID生成方式。

13

优先用EXCHANGE PARTITION迁移分区，速度快压力小，ETL分批迁移也适合大批量数据

14

可以验证一下，即使不能和分区表交换，也可以原分区表和non_partition_table，然后再将备份表的空分区和该non_partition_table进行交换。
负载低。效率一定比ETL这种更快的。

15

分区交换 EXCHANGE PARTITION：零开销、秒级迁移，最适合生产大分区表；

16

自增主键热点本质是Region分裂机制，AUTO_RANDOM通过分布式ID写入分散。

17

只迁移半年以前的历史分区，按分区区间分批迁移，每次只操作一个分区的数据

18

datax

19

方案完全可行，是当前场景下速度最快、对业务写入影响最小的全量迁移方案，远优于批量INSERT ... SELECT。

20

Dumpling + Lightning 就是最快的，怕有影响可以限流