[img_v3_02g3_e0af9891-6a0e-49cc-8788-e5f903e4b25g] [img_v3_02g3_f721e0a8-a038-4953-a933-231e9bfaa42g] 这个问题的原因在这里，是之前的一次开发中引入的，后续重构给修复了。

https://stackoverflow.com/a/59730358/6075468 检查一下是否可能是这个情况？

是否有可能是其他 service 在往同一个 kafka 集群写数据？

麻烦提供一下完整的脱敏的 sink-uri，以及 changefeed 创建配置文件。

监控看起来，outgoing bytes 数量很低，这个值是对每一个 request 大小的记录，也就是说发送端实际每次发送的数据大小。

提供一下 kafka 相关监控内容呢。

你们的数据，最大大小大概在多少？设置到 100mb 的目的是什么？ 检查 cdc 日志，是否有 “invalid request size ” 内容，有的话提供一下。

请提供一下监控. sink-MQ Sink 部分，尤其是 outgoing bytes 这块儿。

错误来自于 nio 层，调大 socket.requet.max.bytes 参数。

先不要操作，我们这边还在调查。

麻烦提供一下 kafka 的版本号。

json 被编码在一起这个问题，和 update 事件拆分逻辑无关。 从 v4.0.13 到 v7.5.3 的过程中，kafka sink 模块经历了重构，其中一项工作，是对于会将多条 events 编码到同一个 kafka message 的协议，会有一个提前赞批的操作，最多一次行赞批 2048 个 events 或者赞批操作耗时超过 15ms。maxwell 属于该种协议。 在编码的时候，maxwell encoder 一次性见到了多条 events，随后就给编码到了一起。

用的是什么协议？

你的问题是什么呢？

该问题的核心就是，用户没有配置 max-message-bytes 参数，老版本上默认为 10mb，你这里同步的消息大小，超过了该值，自然就报错了。 符合预期。 https://docs.pingcap.com/zh/tidb/stable/ticdc-sink-to-kafka#最佳实践

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 语句 …