**环境信息 ** canal v1.1.3-alpha-2 mysql 5.7.27 kafka 2.11
问题描述
2019-01-17 16:56:45.329 [destination = example , address = /10.1.137.68:3306 , EventParser] ERROR c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - dump address es-node1/10.1.137.68:3306 has an error, retrying. caused by com.alibaba.otter.canal.parse.exception.CanalParseException: com.alibaba.otter.canal.parse.exception.CanalParseException: parse row data failed. Caused by: com.alibaba.otter.canal.parse.exception.CanalParseException: parse row data failed. Caused by: java.lang.NullPointerException: null at com.alibaba.otter.canal.parse.inbound.mysql.dbsync.LogEventConvert.parseOneRow(LogEventConvert.java:711) ~[canal.parse-1.1.3-SNAPSHOT.jar:na] at com.alibaba.otter.canal.parse.inbound.mysql.dbsync.LogEventConvert.parseRowsEvent(LogEventConvert.java:533) ~[canal.parse-1.1.3-SNAPSHOT.jar:na] at com.alibaba.otter.canal.parse.inbound.mysql.MysqlMultiStageCoprocessor$DmlParserStage.onEvent(MysqlMultiStageCoprocessor.java:330) ~[canal.parse-1.1.3-SNAPSHOT.jar:na] at com.alibaba.otter.canal.parse.inbound.mysql.MysqlMultiStageCoprocessor$DmlParserStage.onEvent(MysqlMultiStageCoprocessor.java:316) ~[canal.parse-1.1.3-SNAPSHOT.jar:na] at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:143) ~[disruptor-3.4.2.jar:na] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_181] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_181] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
步骤重现
一个实例两个库,本来正常读取binlog的,后来两个库进行多次ddl和dml操作后,一个库正常读取binlog,而另外一个库报错parse row data failed. NullPointerException之类的
原提问者GitHub用户githubkevinyou
可能因为开启tsdb,把example下的h2.mv.db删除,重启canal就能正常解析binlog了
原回答者GitHub用户githubkevinyou
根据你提供的信息,问题可能是由于两个库执行多次DDL和DML操作后,导致binlog中的数据结构发生变化,从而导致Canal解析出错。建议你按照以下方法进行排查和解决:
检查binlog格式和binlog_row_image参数。确定两个库的binlog格式和binlog_row_image参数设置一致,最好使用ROW格式及FULL模式。
清空Canal instance数据目录。Canal启动时会在指定目录下存储instance的元数据信息,如果binlog格式或者中间状态存在问题,可以尝试清空数据目录,重启Canal instance。
检查Canal和MySQL版本是否相同。Canal和MySQL之间的版本兼容性非常重要,如果Canal不支持MySQL的某些特性,可能会导致Canal解析出错。
调整Canal instance的配置参数,例如max_thread_size、memory_storage_buffer_size、batch_size等。这些参数可以影响Canal解析binlog的效率和容错性,适当调整可能会提高Canal的解析能力。
检查Canal adapter的配置信息。Canal adapter需要正确配置,才能将Canal解析的数据写入到目标存储中。
在Canal and MySQL中间添加一层数据中间件(例如Kafka、RocketMQ等),调整Canal和MySQL库之间的数据交互模式,缓解负载压力和解析效率的问题。
结合实际业务需求,可以考虑调整MySQL中的数据操作,减少对表结构和数据的修改,避免频繁的DDL操作对Canal的影响。
可能是两个库的数据结构发生了变化,导致解析binlog时出错。建议检查一下两个库的表结构是否相同,以及是否有新增或删除的表、字段等。另外,也可以尝试重启Canal服务,看看是否能够解决问题。如果问题仍然存在,可以尝试使用Canal的debug模式,查看具体解析binlog时出错的原因。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。