我怀疑是 tiup sclae-in 这个节点的时候，可能部分失败了，即没有成功下线，具体原因未知。按道理来说，cdc 节点下线的时候，会断开 grpc 链接，然后 tikv-cdc 尝试发送数据失败，就会释放这个 grpc stream，从而回收 memory quota。 请你分享一下上面截图中的 tiup log 呢，如果还有的话，也可以给一下如下信息： 执行 scale-in 的时间，看看还找不找的到被 scale-in 的的日志？ 上面截图中的 tikv 节点，在 cdc 节点 scale-in 的时间前后 5 ～ 10 分钟的日志。

请问一下： ticdc 节点缩容是如何操作的，直接 stop 这个节点，还是 scale-in 这个节点？ 能否查一下 192.168.1.114 这台机器上报错的端口，比如 42309，42285， 是否依旧存在，处于一个什么状态？ 你们是如何解决的这个问题？ 正常情况下，scale-in 一个节点，应该是会断开到这个节点的 grpc 链接的。

符合预期，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，随后就给编码到了一起。

用的是什么协议？

你的问题是什么呢？