基于 TiCDC 同步到下游 TiDB丢失数据问题，目前怀疑是两次变更相差 0.001秒相关的问题

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】生产环境
【TiDB 版本】上游TiDBv7.5.2，TiCDC 也是 7.5.2，同步到下游7.5.5
【操作系统】 Ubuntu
【部署方式】阿里云 ECS 上机器部署

【遇到的问题：问题现象及影响】

image
image1671×669 134 KB

如下图，表现是下游丢失一条 binlog （status 始终停留在 INIT），通过使用 tidb snapshot 在上游查询确认是有两次变更，并发现两次变更相差 0.001 秒， TiCDC文档有提及是同一行数据有序同步的。目前怀疑是丢失 binlog 导致，还有什么其他可能或者已知 bug？

【其他附件：截图/日志/监控】

image
image3414×2170 500 KB

这个TiCDC 任务配置如图

2

对于在一个事务内多次修改同一行的情况，TiDB 仅会将最新一次的修改结果发送给 TiKV。因此 TiCDC 仅能获取到最新一次修改的结果。https://docs.pingcap.com/zh/tidb/v6.5/ticdc-faq/

3

有机会的话，可以选择升级 CDC，你用的7.5.2 还有已知BUG修复的。

image
image214×311 1.85 KB

image
image863×349 39 KB

CDC 的模式和 binlog差异很大，想知道更多的差异，下游可以多分发一份到 Kafka，进行查阅

4

这里是丢了 ddl 还是 dml？

5

这在上游也明显不是同一个事务了。同一个事务内的同一行的变更，最终提交后，也就只产生一个版本的 MVCC。但是在上游能看到 2 个版本 MVCC 哦。

6

丢了 DML, 丢了一条对状态的更新的 binlog，下游停留在 INIT 状态了，上游源库已经是 Success 了。

7

是一条 update 还是 insert 丢了？有设置 event filter 吗

8

使用TiCDC 的V7.5.5试试

9

如果可以复现的话，可以尝试ticdc写入到kafka，看下具体的输出；界定是上游解析的问题，还是下游写入的问题；

10

这种疑难杂症可以找support看看

11

NTP 时钟源有没有检查

12

最好看看,同步过滤条件等配置看看,照理说是按照tso同步的啊

13

升级到最新版本试试呢