符合预期，blob 类型的数据，会按照 ISO-8859-1 编码，这是 canal 官方的实现方式。

按照上面提供的方式来解码一下呢。

https://docs.pingcap.com/zh/tidb/stable/ticdc-canal-json/#binary-和-blob-类型 参考上面贴出来的代码，做一下转码

[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，需要修复。