我也遇到过这种问题，最终操作方法也是删除 tsdb 解决的。我建议别关单，这种还是 ng-monitoring-server 的 BUG 导致的，还是需要修复的

[image] 不过貌似 mixed 的级联删除，也是会被记录成 ROW 格式的，那就太奇怪了。。。

上游 MySQL8的 binlog 格式是什么？ 是row 还是mixed 啊？

你的 DM 任务没有同步子表么？ MySQL的 row 格式保证即便是通过外键约束删除的子表，这个删除也会产生 DELETE 类型的 BINLOG EVENT 的

检查原始文件的数据有没有重复的吧，这个是概率最大的

你这种情况大概率是主表，和索引里的数据不一致导致的，用admin check table应该会报错。 题主的问题还不太一样，主键查询就出现问题了，执行索引看起来也没什么问题

可以看下官方文档的原理：因为 TiKV 底层是个 KV 存储，在构成键值对时候，同一个 key 对应的记录天然会被合并成一条。 [image] 可以根据冲突检测， 来看下是否符合预期。其实 local 模式导入新表报错，十有八九就是文件中的数据有重复，或者格式不对导致的 https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode-usage/#冲突数据检测

表已经要设置一个主键，如果都没主键，数据重复了，都发现不了

看下是否是文件中存在冗余数据？ tidb-lightning 的 local 模式会先对所有数据做排序转写成 SST 文件，很可能会将冗余数据汇总成一条

使用 admin check table 看下表是否有损坏吧

下个十年见！

交给 AI 来处理，让它给你拼 SQL

你这个最主要的错误是任务重名了。没有主键只会导致下游 TiDB 上的数据可能出现重复，但是不会导致任务启动不了

类似问题：

[image] 建议按照设置可用区，加下 LOCATION LABELS，TiFlash 只设置副本数为2，是有可能两个副本都分到同一台机器上的。 否则虽然从 region 个数上看起来是均衡的，但可能热点 region 都局限到某一个节点上。

加油！睡眠时间太短容易导致人焦虑，一定要保持睡眠时间

这个时候，其实应该在执行一下binlog-schema update --from-target将 dm 内存中的 60 行schema 更新为下游 TiDB 中 59 行表结构，就可以了。 直接加上--remove-meta，如果task_mode=all可能会涉及到重新导出+导入数据，如果是increment就会只同步增量

如果是位点问题，中间的增量更新也不需要，可以直接调整 task_mode 为 increment，然后指定最新位点来重建任务，记得重建时候加下–remove-meta。 如果增量更新需要，binlog 也没丢，直接在 TiDB 上改成之前的59列的表结构，让正常同步就好了

这个含义是，dm 记录的表 schema 有60列，但是 binlog 中只解析到了59个字段