我用tidb只做一个从库，不会代替生产MySQL主库。
站在各自的立场上，都有合理性，没有对错。
dm确实没有承诺过和mysql复制——甚至报错方式，保持一致。
同时，你的需求仍然可以提。提github上效率会高一些。链接在上面。
或者尝试其他一些的同步工具，看是否满足需求也是可以的。datax,cloudcanal之类的。
如果数据真的是一条几万块的话，确实需要一些商业支持，才睡得着。应该花点，这点钱不值得省。
这个应该可以做，没啥难度
提个需求呗，怎么前面好像见过这个呢
好像不行
可以反馈一下
提需求问问行不行
这不叫Bug，市面上也不会有这样的同步工具。
哪怕是同构数据库也是要求目的库只读才能实现你说的完全一致。
做应该能做的到，但数据多了个校验，性能也会有影响，况且要是因为这导致dmt
到不能说是bug, DM只是迁移工具
我觉得，无论是迁移过程，还是持续的数据同步过程，都应该保证源端、目标端所执行SQL的影响行是相同的。有主键要求，如果是update的话，源端update10行，目标端update5行，丢失的5行不报错也要warning警告或者replace into补录进去。
1 个赞
如果不是类似复制库这种功能或者是备份库功能，下游数据库有自主操作的，没有办法限制上下游的数据一致性。
Mysql 主从同步也不能检测数据一致性啊，你这是下游删除，它同步不了报错 1032 了，你如果是更新下游，它一样不会报错啊🤔
DM 产品设计上并没有说和 Mysql 主从同步行为一样
不支持一致性检测的
我测试了下，按照官方提供的《 DM 增量数据校验》方法，可以检测到这种情况。
在下游tidb删除记录，上游mysql更新删除的记录。
区别与mysql主从复制，dm复制不会停止。
注意整理数据校验的限制条件，如要求有主键和非空唯一键等。
[https://docs.pingcap.com/zh/tidb/stable/dm-continuous-data-validation](https://DM 增量数据校验)
1 个赞
感觉超出了DM工具的范围，只是做同步迁移使用，要是为了一致，需要保证从库没有读写，使用工具校验数据是否一致，就像阿里的DTS一样，
dm是用来做数据迁移的工作，如果需要数据校验，可以使用sync-diff-inspector工具
为什么从库要给删除权限？
这个提了不一定会做，有点偏离。