TiCDC Update 行为变更是否影响 Canal-JSON

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.5.1
【复现路径】无
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
问题:根据官方文档发现 TiCDC 后续的 Update 行为有部分会被拆分为 Delete + Insert,是否会影响 Canal-JSON 协议?
背景:计划 TiDB 从 5.x 升级到 7.5.1
业务中会用 Canal-JSON 获取变更前后值写做数据的变更日志(记录某个数据的部分字段的变更日志),若 v7.5.1 会将一条 update 的 Canal-JSON 拆成两条 Delete + Insert,那业务会误认为进行了一些字段的新增,而非变更

如果把更新拆分 删除 和插入。且你们用到了csv和avro协议会可能仅输出新值的话,应该会有影响。我理解的是因为没法更新前后的比较了。

TiCDc 的 Update 行为变更可能会影响 Canal-JSON 的工作原理。TiCDc(TiDB Data Change Detection)是 TiDB 的数据变更捕获工具,而 Canal-JSON 是用于 MySQL 的数据变更捕获工具,它依赖于 MySQL 的 binlog 日志来追踪数据的变更。

如果 TiCDc 的 Update 行为变更意味着它不再遵循 MySQL 的 binlog 日志格式,那么 Canal-JSON 可能无法正确解析和识别这些变更。这种变更可能会导致 Canal-JSON 无法正常工作,或者无法正确地捕获 TiDB 的数据变更。

解决方法:

  1. 检查 TiCDc 的更新日志,了解变更的具体内容。

  2. 如果 TiCDc 更改了日志格式,检查 Canal-JSON 是否支持解析新的日志格式。

  3. 如果 Canal-JSON 不支持新的日志格式,考虑更新 Canal-JSON 或者寻找替代方案,使用兼容 TiDB binlog 格式的数据变更捕获工具。

  4. 如果可能,可以尝试配置 TiCDc 使用与 MySQL 兼容的日志格式,以便与 Canal-JSON 兼容。

  5. 如果以上方案不可行,可以考虑自己开发一个工具,解析 TiCDc 的日志格式,并转换为 Canal-JSON 支持的格式。

我们只用到了 canal-json 协议,理论上可以考虑做更细粒度的根据协议判断,而不是 sink 类型(MySQL、MQ),现在看代码好像是只用 sink 类型判断
image

原来以为是由优先级的概念,如果有主键,唯一索引更新就不会进行拆分,但看代码目测不是这样,是主键或唯一索引更新都会进行拆分。


kafka 这种拆分可以认为是要解决第 2 个问题,key 变更会被拆分到两个 partition,但 key 默认是主键,如果存在主键,此时变更应该还是在一个 partition 上,不会分发到两个 partition 上。
因此理论上,存在主键的 mq 数据源,唯一索引的更新可以考虑不被拆分。
正常业务主键都是自己生成的分布式 ID,或者 TiDB 的随机 id,可能会发生唯一索引变更,不会发生主键变更。