后续版本有修复哈 [image]

为什么不用 tiup 下线？

[image] https://disksing.com/tikv-replica/

关掉这个配置就好了 https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-configuration [image]

你的 DM 任务配置文件是配置的 mode: full 吗？ 如果是 full 那全量导入是一次性的，任务完成后就没有了，后续想继续开一个增量任务直接开就行 如果是 all，那全量结束后会自动开始增量同步，不需要其他操作。 https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full task-mode: all # 任务模式，可设为 “full” - “只进行全量数据迁移”、“incremental” - “Binlog 实时同步”、“all” - “全量 + Binlog…

你起码贴一下 DM 的报错吧

dm 有没有配置 gtid

贴一下配置文件吧，是按照文档做的么，https://docs.pingcap.com/zh/tidb/stable/migrate-aurora-to-tidb/ 如果是的话，是不是没有在 dm 配置文件里面填 binlog file 和 binlog pos

老哥，你这要求有点高啊。用并行导入测一下吧。只能横向扩展了，硬件都得拉满才行，还要注意下游 tikv 别被打爆了

[image] https://docs.pingcap.com/zh/tidb/stable/table-filter

hahaha，平安夜在家里做了一顿大餐！

gihub id: okJiang

卡住多久呢？又可能 check-task 就是在运行，这个命令是同步的，可能会运行久一点。 先找到 DM 日志看下吧

对于 mysql 数据源是有解决方案的，可以使用 dumpling 在导出的时候指定导出的 null 值。https://docs.pingcap.com/tidb/stable/dumpling-overview [image] 对于非 mysql 数据源，暂时应该没有计划，可以上 https://github.com/pingcap/tidb/issues/new/choose 提 issue 试试

寻求方便的话，可以直接参照 快速上手，使用 dumpling 在 mysql 中导出数据。这样导入起来更丝滑~

使用 tidb-lightning https://docs.pingcap.com/zh/tidb/stable/get-started-with-tidb-lightning 并注意文件的命名格式

tikv 本身对数据就会进行压缩，lightning 物理模式会对数据进行排序后再导入 tikv，所以压缩效果会比逻辑模式好一些。 checksum 成功了不用担心数据损失，本来不同的插入方式插入 tikv 之后最终的存储大小都是会有误差的，这很正常。