Bug 反馈
TiCDC6.5.6 同步数据到下游Kafka，出现上下游事务顺序不一致问题。
上游TiDB数据库先对xxx_lesson表进行insert操作，再进行update操作（跟insert不是同一个事务）。下游kafka接收到消息顺序是先update操作后insert操作。
TiCDC任务具体参数配置：
tiup ctl:v6.5.6 cdc changefeed create protocol=canal-json&enable-tidb-extension=false&transaction-atomicity=none&content-compatible=true
【 TiDB 版本】
TiDB 6.5.6
【 Bug 的影响】
上下游事务顺序不一致问题
【可能的问题复现步骤】
【看到的非预期行为】
上下游事务顺序不一致
【期望看到的行为】
上下游事务顺序一致
【相关组件及具体版本】
TiDB6.5.6、TiCDC6.5.6
【其他背景信息或者截图】
记着ticdc是按照表 排序的吧。两个事务的时间没问题？
TiDB6.2以后 transaction-atomicity默认是none，如果下游是mysql可以配置成table。不清楚是否跟这个有关系。
上游两个事务的时间顺序没有问题，先insert再update。
大佬nb，那下游就得增加watermark了吧
sorry，没仔细看截图，如果下游 partition 都是 2 相同，那 partition 内部一定是有序的（否则就是 bug
建议开一下 commit_ts 明确显示记录的先后顺序，你截图应该是 Canal-JSON Protocol 看一下对应文档 https://docs.pingcap.com/zh/tidb/stable/ticdc-canal-json#tidb-扩展字段
如果同一个事务里有三张表每张表都执行一条insert，那它们的commitTs相同吗？
操作流程：
业务侧在同一个事务里对三张表进行insert操作顺序是
bs_cla->bs_cla_extend->bs_cla_fertile
kafka输出结果：commitTs
450886139727839290 bs_cla_fertile
450886139727839277 bs_cla
450886139727839271 bs_cla_extend
tiup ctl:v6.5.6 cdc changefeed create ?protocol=canal-json&enable-tidb-extension=true&transaction-atomicity=none&content-compatible=true
insert_时间戳_v2.txt (3.2 KB)
数据同步流程：
业务写入MySQL5.7，通过DM2.0工具同步表数据到TiDB 6.5.6版本，然后通过TiCDC推送数据到 KAFKA
MySQL–DM(2.0)–>TiDB(6.5.6)–Ticdc(canal-json)—>kafka
目前从上游MySQL binlog日志分析看跟业务插入(三张表在同一个事务中)的顺序一致性bs_cla->bs_cla_extend->bs_cla_fertile经过DM2.0到TiDB上顺序变为bs_cla_fertile->bs_cla->bs_cla_extend了。
DM 的不能绝对保证事务的一致性，因为它是数据迁移工具，不能用于后面的事务一致性顺序消费。建议 MySQL 到 TiDB 如果要进行顺序数据的处理，可以尝试 Flink CDC 方案。
DM 文档链接 https://docs.pingcap.com/zh/tidb/stable/dm-dml-replication-logic#注意事项
通过 TiCDC 打点数据记录看到，看 ES 的值 (es = commitTS / 2^18) 确实是后面那条有更小的 tso 呀, 所以在 watermark 之前按 commitTS 排序还是有正确的顺序的。 TiCDC 发给 Kafka partition 是一条条顺序发宋，不过截图看到是 dataSize:2，有没有可能消费端有做什么合并的操作掉乱次序呢？看两条记录的 ts 都是 1719533982904 即是这两个 message 是在同一毫秒发出的
1719533981928 = 2024-06-28 08:19:41.928
1719533981879 = 2024-06-28 08:19:41.879
TiCDC 数据同步字段介绍
建议关注一下下游 TiCDC 消费端的处理方式，是否可能将 2个 message 合并到一起。
非常感谢！
