MySQL数据同步至TiDB,使用DM工具,在load阶段会大量消耗下游IO,能不能降速,或者有没有其他更好的替代方案

通过DM把MySQL的数据同步至TiDB,load相关参数如下:

  loader:
    pool-size: 2
    dir: ./dumped_data
    import-mode: sql
    on-duplicate: replace

当同步任务进行至Load阶段,下游TiDB部分节点IO几乎被打满:

服务器磁盘的写流量也非常大:

目前下游TiDB已经在跑生产业务了,IO打满的影响还是比较大的。官方文档看DM的Load阶段貌似没有什么好的限流措施,这种情况还能做些什么优化?

手动导入吧。

手工导入是用myloader做导入吗?因为下游在跑业务,高峰期Load需要暂停一段时间,很多导入方式不支持暂停。

另外DM的all模式全量+增量全部能搞定,手工导入的话自己还要再处理增量的部分,后续还要好多个系统要迁移,这样会加大运维工作量 :joy:

load size 不行调整为 1,还不行就手动吧。没啥办法了。

麻烦提供下 dm/tidb 的版本信息,以及相关节点的具体配置。dm 的详细配置麻烦也发下

另外从截图看,tidb/tikv 是跑在同一个节点上的?

dm 在 load 阶段是执行 SQL语句,此时不应该有这么高的磁盘 IO 操作,按说升高的应该是网络 IO(写 TiKV)。在截图这段期间有添加 Index 的操作吗?

6.2.0 之前的版本 DM 无法配置 load (使用 lightning)并发度,6.2 之后可以通过 pool-size 配置。如果版本较低的话,建议升级下

dm是v6.5.0
TiDB是v6.1.2

tidb和tikv是独立部署的,一台tikv服务器部署3个tikv节点,每个节点都是独立的2T nvme盘。

这段时间下游tidb没有进行DDL操作。

其中一台tikv服务器的流量:

同一台服务器的io使用率:

附件是DM的完整配置:
dm配置.txt (2.6 KB)

我们之前用dm迁移速度很慢,用的自己写的dts工具快不少,还有很多商用的数据同步工具,可以找一下