好嘞,那这个是有版本限制吗。是否适用于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触发条件是什么呢,主要是想了解一下触发条件,然后看看能不能规避
4.0.13,任务状态没报错,cdc.log也没错误记录,只有cdc_stderr.log日志一直在刷上面的日志
如果是数据包大导致没法接收,任务信息会提示【message was too large】
kafka是上级公司的,我们是子公司没法去查看,也没法申请变更配置之类的。
只要满足 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格式,其他数据没问题,只是一部分数据有问题