大数据量的分库分表合并到tidb 为啥不建议用DM的full模式

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】6.1.0
文档上建议数据量大于1T的分库分表合并到tidb,建议dumpling+lightning+dm increment模式,我想问下,如果大于1T的分库分表或者数据规模接近800G,并且分库较多,如果用DM all模式同步会有什么问题,如果用dumpling+lightning+dm方式,是不是下游的表要手动建

任务模式:
“full” - “只进行全量数据迁移”
“incremental” - “Binlog 实时同步”
“all” - “全量 + Binlog 实时同步”

应该只是根据不同场景选择吧。

1 个赞

https://docs.pingcap.com/zh/tidb/dev/migrate-large-mysql-shards-to-tidb

我说错了 我指的是all模式 不是full模式
如果用dumpling+lightning+dm方式,是不是下游的表要自己建

DM直接有分表合并数据迁移最佳实践吧

https://docs.pingcap.com/zh/tidb/stable/shard-merge-best-practices

:grinning:

用dm就可以满足了设置为all模式,会自动建表

我的问题是为啥官方文档不推荐在大数据量的场景下 用dm的all模式同步数据,会有什么样的问题

盲猜,用all模式占用了磁盘,但是后续不会用到这些磁盘

1 dm是会锁表的 2 还不支持断点续传

也可以用,主要是时间比较长

若要迁移分表总和 1 TiB 以上的数据,则 DM 工具耗时较长,可参考从大数据量分库分表 MySQL 合并迁移数据到 TiDB
https://docs.pingcap.com/zh/tidb/dev/migrate-small-mysql-shards-to-tidb

如果用dumpling+lightning+dm方式,是不是下游的表要自己建

最好是自己建,在 lightning 导入的时候需要合并导入哪个库表,就建好哪个库表,自己保证它和上游的兼容性。