你起码贴一下 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 之后最终的存储大小都是会有误差的，这很正常。

lightning 确实处理 ,“”, 和 , 的行为是一样的

现在可能还是 dumpling+lightning 比较快。。后续新的版本会出 import into select，速度更快

其实还真有，只不过文档中没有说过（不知道为什么） 使用方法可以参考这个测试样例 https://github.com/pingcap/tiflow/blob/master/dm/tests/extend_column/conf/dm-task.yaml 这是 issue https://github.com/pingcap/tiflow/issues/3340

每行都有一个 rowid key-value 的映射关系 索引 id => rowid rowid => row

谢谢社区，收获颇丰～