配有，这个参数在MySQL我们没有配置，而且用2.0.3版本的时候用了2线程并发，执行了3h55min报错，用6.1.7版本的时候用了8线程并发，执行1h5min报错，侧面也反应了这个应该不是MySQLkill的连接

试了tidb4.0.13版本也是报一样的错误，都是全量备份到中途就报上面的错误了，整库大概2T，备份到1.3T就报那个错了，所以感觉跟dm的版本没关系呢

创建任务的时候呗，dmctl:v6.1.7

是dm的版本还是dmctl的版本，我看了dm没有6.1.7版本，dmctl倒是有6.1.7. 所以疑惑，我现在是要升级dm还是dmctl，然后升级到哪个版本

好嘞，那这个是有版本限制吗。是否适用于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建议怎么配置才不会导致报这个错误呢。

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