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

[ealam_小羽]

【 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，那业务会误认为进行了一些字段的新增，而非变更

[The-Fallen-Angel]

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

[zhh_912 (Ti D Ber Cv4 Exo1 H)]

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 支持的格式。

[ealam_小羽]

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

[ealam_小羽]

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

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