【TiDB 使用环境】生产环境
【TiDB 版本】8.5.1
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】1T
【集群节点数】3
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
计划将多个分片的分表合并为一张表，现在遇到一个问题，想咨询一下tidb有内有这样的风险：
多个分表增量数据复制到tidb时，数据可能有先后的顺序（因果序），那么DM保证数据写入的因果顺序吗？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
不保证，只能保证最终一致性。
https://docs.pingcap.com/zh/tidb/stable/dm-dml-replication-logic/#精确一次处理-exactly-once-processing
目前 DM 仅保证最终一致性，尚未支持“精确一次处理”及“保持事务原有顺序同步”。
文档里面写的非常明确。
这个应该保证不了吧。分布式保证全局因果应该比较麻烦，自增列全局自增都是等了好多个版本才等到。
多个分片上的怎么知道你的因果序，DM 一个数据同步统计不可能把你业务逻辑写进去吧
实际上的情况是，DM 同步时单个分片也无法保证同步顺序，DM 为了同步效率，进行了事务拆分和并行，仅能保证最终一致性
我理解多分片分表合并为一张表，最终一致性也保证不了，因为可能因果逆序
最终一致保证不了，还能是同步么？同步肯定要保证最终两边数据一致吧。
1 个赞
我看1楼的链接了，文档说的应该是单链路可以保证最终一致性，这个是没问题的。但是多条链路，无法协调事件的顺序，所以数据一致性不能保证，只能通过对增量数据动态做一致性校验，来确认数据没问题，我是这样理解的。
链接里没看到你说的这个
文档只说了单链路，多个复制链路没说，我只是说了我的理解结论，哈哈
哦哦，我觉得你说的对。
dm worker和source是一对一的，除非你的source上会出现因果逆序，否则不会出现你说的这个问题。
不知道你们的业务是怎么设计的，分表分库应该也不会让一个key的最终读取结果需要考虑多个source吧。
不可以的
感觉不行
假设源有3个库
在某一时刻，源库的某一行的数据分别是
1 4 7
2 3 4
3 5 8
DM 同步到目标库，如果楼主期望 TiDB 只能看到
1
2
3
或者
4
3
5
或者
7
4
8
不允许出现
1
3
5
那估计DM做不到吧。DM 应该是只能做到最终如果源库停止了写，能看到 7 4 8
1 个赞
分库分表合并为一张物理表，还得保证因果序列，这需要一个全局时钟才行，不止DM保证不了，其它任何同步软件都不行吧，最多只能最终一致性。毕竟你分库分表的架构本来就没有全局时钟来统筹这些。