从现象看，记录的是一条完整的记录，不是截断那种，尾部有分号

刚才去慢日志查看发现也是没有where条件

已经更新

你需要的信息已经更新了帖子

请问使用output-raw-change-event=true有什么风险吗

配有，这个参数在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是上级公司的，我们是子公司没法去查看，也没法申请变更配置之类的。

重新起了一个帖子