ticdc将update拆成delete+insert问题

tidb版本 7.5.3
协议 maxwell

最近从4.0.13升级到7.5.3,升级后的几天业务反馈ticdc很多时候会将update拆成delete+insert,有一少部分update会保持原样。

目前触发原因未找到,被拆成delete+insert后有个槽点,就是会将两个json怼在一起,变成非标准json串,导致业务代码无法正常解析,进而影响到下游消费。

即:业务的原操作是update,如下

{
  "database": "xxxx",
  "table": "xxxx",
  "type": "update",
  "ts": 1725939150,
  "data": {
  }
}

ticdc会拆成下面这样

{
  "database": "xxxx",
  "table": "xxxx",
  "type": "delete",
  "ts": 1725939150,
  "data": {
  }
}
{
  "database": "xxxx",
  "table": "xxxx",
  "type": "insert",
  "ts": 1725939150,
  "data": {
  }
}

现在的问题:
(1)update被拆成delete+insert的触发条件是什么
(2)update拆成delete+insert能否有什么手段可以让ticdc将两个json放在一个列表,变成下面这样

[{
  "database": "xxxx",
  "table": "xxxx",
  "type": "delete",
  "ts": 1725939150,
  "data": {
  }
},
{
  "database": "xxxx",
  "table": "xxxx",
  "type": "insert",
  "ts": 1725939150,
  "data": {
  }
}]

可以参考下这里
https://docs.pingcap.com/zh/tidb/stable/ticdc-split-update-behavior#mysql-sink-拆分-update-事件行为说明

1 个赞

用的是什么协议?

  1. update 拆分的触发条件可以看这个文档 https://docs.pingcap.com/zh/tidb/stable/ticdc-split-update-behavior#非-mysql-sink-拆分主键或唯一键-update-事件

  2. 非常抱歉 Maxwell 格式还没有正式支持,所以建议用别的支持的格式:https://docs.pingcap.com/zh/tidb/stable/ticdc-avro-protocol

升级之前没有遇到问题,可能是因为没有触发 update 拆分的逻辑。总之建议改用别的数据格式(基本也都是用 json)

1 个赞

请问使用output-raw-change-event=true有什么风险吗

json 被编码在一起这个问题,和 update 事件拆分逻辑无关。

从 v4.0.13 到 v7.5.3 的过程中,kafka sink 模块经历了重构,其中一项工作,是对于会将多条 events 编码到同一个 kafka message 的协议,会有一个提前赞批的操作,最多一次行赞批 2048 个 events 或者赞批操作耗时超过 15ms。maxwell 属于该种协议。

在编码的时候,maxwell encoder 一次性见到了多条 events,随后就给编码到了一起。

output-raw-change-event=true 确实可以阻止 update 拆分,风险就是需要自己承担不拆分带来的下游数据和上游不一致的风险。如果业务逻辑可以容忍或者有其他机制能保证,就 OK

1 个赞

是Maxwell格式吧😂,兄弟7.已经不维护了,之前测试Maxwell格式7.,8.都有问题,我用5.,目前没有遇到问题

不光这个问题,数据合并,增加列有默认值都会报错,如果必须依赖Maxwell 格式cdc我劝你退到5.4.1如果不强制更改为canal

下面给你我的两个异常记录
ticdc 增加有默认值字段后异常
tidb cdc 同步数据异常