好嘞，那这个是有版本限制吗。是否适用于4.0.13版本或者4.0.16版本？ 现在我们是测试阶段，如果canal-json在4.0.13版本也生效，那我们就可以先不用升级了

试过仅配置max-message-bytes=4MB的，但是也报错，所以现在都不知道要咋配置了 从诸多协议测试来看maxwell可读性比较好，所以最终敲定这个协议，那官方GA的协议是哪个呢，建议使用哪个协议呢，针对这种下游kafka限死4MB的场景，在该协议下，ticdc端的参数又怎么配置呢

我的意思，kafka是别人的系统，不归dba管，dba只是用户端，服务端不支持变更配置，人家是统一管理配置的

kafka是全公司全局标准化的配置，暂时不支持变更配置，所以比较尴尬，先试试将message改成256KB试试吧

1.0->2.0->2.1->4.0,每次都是一有问题就让升级，这种解决方案真是让人难以言喻

这个bug触发条件是什么呢，主要是想了解一下触发条件，然后看看能不能规避

#TiDB 67w 满电超充插头

4.0.13，任务状态没报错，cdc.log也没错误记录，只有cdc_stderr.log日志一直在刷上面的日志 如果是数据包大导致没法接收，任务信息会提示【message was too large】

kafka是上级公司的，我们是子公司没法去查看，也没法申请变更配置之类的。

重新起了一个帖子

已经改成2还是会报错，郁闷

但是实际使用发现，还是报错，比较郁闷 [图片]

只要满足 cdc max-message-bytes * max-batch-size <= Kafka 的 max.message.bytes 就不会出现再这个报错？

现在我们的Kafka 的 max.message.bytes限制了4m，现在能保证的是，单行数据肯定不会超过4m，现在cdc max-message-bytes 配置4m，2m，1m都会报错（ticdc任务有9个表，每个表的单行都不会超过4m，但是存在同时刻各个表都有变更），所以现在想请问ticdc建议怎么配置才不会导致报这个错误呢。

更新了内容，烦请重新看一下帖子

远远达不到限制的数据长度，而且在同实例下的其他库的一样表结构的表就没问题，而且只是部分数据有问题，刚才又测试出新的问题，直接update也不会更新，而且直接delete也不会被删除掉 update返回 Rows matched: 1 Changed: 1 Warnings: 0 delete返回 Query OK, 1 row affected

general log看到是悲观事务 txn_mode=PESSIMISTIC

数据比较敏感不方便看，语句没问题的，一样的sql格式，其他数据没问题，只是一部分数据有问题

看了网络，没啥问题，操作系统时间没法追溯了