enable-old-value 参数默认为 true，无需进一步设置。 依旧输出 old-value 这应该是一个 bug，需要修复。

我发现，在 v7.1.1 分支上，这个 PR 就已经进了，你们之前使用该版本，应该已经有这个行为了才对。

config(ticdc): enable-old-value always false if using avro or csv as the encoding protocol (#9079) by ti-chi-bot · Pull Request #9318 · pingcap/tiflow (github.com) 这个 PR 一次性改动的内容比较多，release-note 只覆盖了部分内容。 后续我们会对文档加以更新，说明情况。之后也会注意这种前后行为变化的修改。 单表单 partition，存在的一个问题是，cdc 吞吐量有限，kafka consumer 消费速率也不能…

各位好，我是该功能的开发者，很高心看到大家对该问题的探讨。 cdc 到 kafka 链路，没有 safe-mode 参数。 在使用 kafka sink 的情况下，update 事件的拆分逻辑如下。对于单条 update 事件，如果发生了 primary key 或者 unique key 的修改，那么拆分为 delete + insert 语句。 关于 update 事件拆分，用户观察到的是输出内容发生了改变。该行为变更，表面上是对某些协议，如 avro，csv 的兼容，实际上它还牵扯了其他模块的功能正确性，如 index-value dispatcher。 考虑如下 SQL 语句 …

目前官方推荐使用的是 canal-json 和 open-protocol。 如果使用 canal-json，直接使用默认的参数配置即可。 canal-json 是单个 DML event 就是一条 kafka 消息。Open-Protocol 是多个 DML events 一条 Kafka 消息，max-batch-size 参数生效。 参数直接使用默认的即可。

使用的协议是 maxwell，该协议会对多个事件做 batch 操作。从源代码上看，max-batch-size 在该协议上是不生效的。maxwell 不是 TiCDC 官方 GA 的协议。 从给出的配置来看，max-message-bytes 给的值是 262144，即 256k。如果一次性 batch 的消息大小操过该值，就会发生 message too large 的做错。 即然你的下游 kafka 给的消息大小限制是 4MB，你完全可以不用管该参数啊，或者也给个 4MB 即可。

你目前使用的 cdc client 是 6.6.0 版本，和 server 的版本不匹配。 建议升级到 server 对应版本再试一下。

unsupported type 来自于打 log 时，某一个对象存在一个 callback，zap 无法识别 callback 导致，和卡住问题应该是没有关系。

这个也不是导致进程退出的根本原因。 要找到 region feed stopped 的原因。

从提供的材料来看，不知道 owner 切换的原因。可以查看切换之前的 cdc owner 节点的日志，看看是因为什么原因导致它从 owner 上退下来。 新的 owner 在 2022/11/20 12:32:11.153 +00:00 当选。可以看看老的 owner，在这之前 2 分钟左右的日志，或者搜索 [ERROR] 或者 [WARN] 级别的日志。

leader 变化和 owner 变更之间的时间差了 1 分钟，关联性可能不大。之前的 owner 节点挂掉可能是因为其他原因。 owner 挂掉之后，新的 owner 会自动选举出来。之前挂掉的 owner 节点上的同步任务，会自动地被迁移到其他存活的 TiCDC 节点上。

相关 PR cdc/codec: Fix canal json encoding by 3AceShowHand · Pull Request #3677 · pingcap/tiflow (github.com) cdc/codec: fix nil value in canal codec. by 3AceShowHand · Pull Request #4741 · pingcap/tiflow (github.com) cdc/codec: fix string for unsigned value in canal-json. by 3AceShowHand · Pull Req…

提供的报错 call stack 和 v5.4.0 的代码内容对应不上，请用户检查确认版本，提供 commit hash。

tiup/main.go at master · pingcap/tiup (github.com) tiup 宿主机，会存有各个组件的 binary，它直接调用这个 binary，执行相应的命令。也就是说，发出命令的是 tiup 宿主机，而不是被放置在某一个远端的 cdc。 至于访问 kafka，这是在 tiflow/sink.go at master · pingcap/tiflow (github.com) 当执行 cdc cli changefeed create --sink-uri="kafka://xxxx" 的时候，cli 会调用这部分代码。 tiup ctl:vxxx…

问题是发生在使用 tiup ctl 创建 changefeed 阶段么？这个阶段，访问 kafka 的是 tiup ctl，所以需要有访问 kafka 的能力。

这是内部的 request，从 TiCDC 发往 TiKV，并且有返回 response 说当前 region 不是 leader。 changefeed没有接收到request的问题。changefeed 不需要去收 request。 建议多重试一下。

sink-uri 中的参数，只是指定 kafka 相关的行为，此处设置为 partition-num=1 是没问题的。 从已有信息来看，问题不在 sink-uri 的配置上，--sink-uri=“kafka://127.0.0.1:9092/kafka-canal-json-test2-topic?protocol=canal-json&partition-num=1&max-message-bytes=67108864&replication-factor=2” 是一个合理的配置，上述配置需要保证： 因为 replication-factor = 2，下游 kafka 集群至少要…

自 5.4 版本开始，delete 类型的事件，相关的数据，将会存放在 Data 字段，这符合 Canal 官方对 Canal-JSON 格式的实现。 old 字段，在 canal-json 的定义中，用于存储之前的数据，仅被 Update 类型使用，其他情况均为 null。 消费端程序，处理 Delete 事件时，应该处理 Data 字段。 TiCDC Canal-JSON Protocol | PingCAP Docs

mch_id 这一列，允许存在 null 值，并且未插入，可以通过给该列赋一个默认值来绕过这个问题。 该问题已经有 PR，下个版本修复。