我的MYSQL主库上有一张t1表，有5条数据，然后我故意在TIDB上把这5条数据删除，然后我回到上游MYSQL上执行update全表更新，我再回到TIDB上，执行query-status并没有报错，如果是MYSQL，这里应该是1032错误，并且停止同步，然而TIDB DM并没有提示DBA有错误，这无法发现数据不一致。
请问这个BUG何时修复？如果不能检测到数据不一致，tidb作为从库是无法提供给业务使用的，尤其涉及到金融业务，一条数据就有可能是几万块，产品算错数据了，dba直接P0 事故。
https://docs.pingcap.com/zh/tidb/stable/dm-continuous-data-validation
看看这个是否对你有所帮助，我没有试过，不是非常确定。
2 个赞
- 本来在下游 TiDB 目标库表就是不应该修改的，只能读取
- 这个事情和 DM 没有关系，DM 只是负责解析上游的 binlog 并在下游回放，举个例子，如果你没有在下游删除而是插入了，那这时候应不应该报错呢
- 如果需要发现数据不一致的话， TiDB 提供了工具叫 sync-diff-inspector[https://docs.pingcap.com/tidb/stable/sync-diff-inspector-overview]
2 个赞
多谢，我下午测试一下。我就是这个意思。
我同意 @onlyacat 的说法。
检测->修复这种是比较被动的应对这个问题了。
也许可以做到，但是代价肯定是非常大的。为了应对偶尔的非预期写入，投入的资源将是产生这个问题的好几倍。
最好的办法还是回收除了dmuser以外的所有用户对同步表的写权限/ddl权限。
杜绝下游产生非预期的写入/表结构修改是最好的办法。
我已经测试了，不管用，跟MYSQL的机制不一样，无法报错1032错误。
1 个赞
这是一个功能，要跟MYSQL完全一样的机制，主从数据不一致，必须告警，让DBA知道，你可以了解一下MYSQL 1032错误。希望官方可以尽快解决这个BUG
不，你去看看MYSQL 主从同步复制机制，DM应该类似，我不管用什么方法，数据不一致，就必须报警，这是最基本的功能，你不能报警出来，后续的数据就不一致了，造成的故障就是P0！！！！
感觉这个就是DM工具的设计思路吧。
TiDB 不是 MySQL, DM 也只是一个周边工具。这不是最基本的功能，你先去了解下 MySQL 的主备复制原理吧，如果你有这个需求直接向官方反馈，虽然我感觉应该不会做。
去向官方提需求看看
MySQL 1032错误你先了解一下。
请问有邮箱吗？我给他们提个需求
我的需求是：要和MySQL同步复制一样，如果出现了1062和1032错误，同步中断，dm给出报错信息，dba通过脚本监控到自行解决。如果官方可以看到这个帖子，希望可以增加一下这个功能。
1 个赞
怎么说呢，这算 bug 吗？我觉着不算。文档对于 dm 的定义说的很清楚，它就是一个便捷的数据迁移工具，能做数据同步吗？能做，但也是为mysql 迁移到 tidb 而服务的，也就是有朝一日，终要切换到 tidb，如果在切换之前，你非要拿 tidb 当下游，mysql、tidb 都开放给业务做双写，那我觉着你就不应该用 dm，或者说自始自终你架构选择思路就错了。下游备库就只是备，在作为备的那一刻，就应该只读，如果哪天你在备库写了，删了数，然后怪工具存在缺陷？有点意思
1 个赞
我也是这么觉得，只是迁移的时候用一下，短暂同步，他不是为了让你长期同步的，你要是不去用tidb,就不用迁移了，如果准备使用tidb,那迁移完就要考虑赶快切换了，他只能保证迁移过程中数据一致，不能保证同步期间一致性
1 个赞
我是用tidb做一个从库，提供给业务查询复杂sql的，不写数据。我只是人为测试一下dm是否跟mysql的复制机制一样。MySQL遇到同步复制报错后，会自动断掉sql_thread线程，执行show slave status会看到具体的报错信息，等待dba修复好数据后，dba再执行start slave开启同步。我是希望dm可以跟mysql的复制机制一样。