开发者社区> 问答> 正文

两个库进行多次ddl和dml操作后,一个库正常读取binlog,而另外一个库报错parse row

**环境信息 ** 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

展开
收起
古拉古拉 2023-05-08 14:59:51 97 0
3 条回答
写回答
取消 提交回答
  • 可能因为开启tsdb,把example下的h2.mv.db删除,重启canal就能正常解析binlog了

    原回答者GitHub用户githubkevinyou

    2023-05-09 18:04:04
    赞同 展开评论 打赏
  • 根据你提供的信息,问题可能是由于两个库执行多次DDL和DML操作后,导致binlog中的数据结构发生变化,从而导致Canal解析出错。建议你按照以下方法进行排查和解决:

    1. 检查binlog格式和binlog_row_image参数。确定两个库的binlog格式和binlog_row_image参数设置一致,最好使用ROW格式及FULL模式。

    2. 清空Canal instance数据目录。Canal启动时会在指定目录下存储instance的元数据信息,如果binlog格式或者中间状态存在问题,可以尝试清空数据目录,重启Canal instance。

    3. 检查Canal和MySQL版本是否相同。Canal和MySQL之间的版本兼容性非常重要,如果Canal不支持MySQL的某些特性,可能会导致Canal解析出错。

    4. 调整Canal instance的配置参数,例如max_thread_size、memory_storage_buffer_size、batch_size等。这些参数可以影响Canal解析binlog的效率和容错性,适当调整可能会提高Canal的解析能力。

    5. 检查Canal adapter的配置信息。Canal adapter需要正确配置,才能将Canal解析的数据写入到目标存储中。

    6. 在Canal and MySQL中间添加一层数据中间件(例如Kafka、RocketMQ等),调整Canal和MySQL库之间的数据交互模式,缓解负载压力和解析效率的问题。

    7. 结合实际业务需求,可以考虑调整MySQL中的数据操作,减少对表结构和数据的修改,避免频繁的DDL操作对Canal的影响。

    2023-05-08 15:14:15
    赞同 展开评论 打赏
  • 随心分享,欢迎友善交流讨论:)

    可能是两个库的数据结构发生了变化,导致解析binlog时出错。建议检查一下两个库的表结构是否相同,以及是否有新增或删除的表、字段等。另外,也可以尝试重启Canal服务,看看是否能够解决问题。如果问题仍然存在,可以尝试使用Canal的debug模式,查看具体解析binlog时出错的原因。

    2023-05-08 15:13:50
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
PolarDB-X 2.0 全局 Binlog 与备份恢复能 立即下载
低代码开发师(初级)实战教程 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载