开发者社区> 问答> 正文

数据库数据新增或更新后canal数据无变化

环境信息

canal 1.1.3 mysql 5.7.24

问题描述

2019-02-01 11:04:08.881 [main] INFO c.a.o.c.i.spring.support.PropertyPlaceholderConfigurer - Loading properties file from class path resource [canal.properties] 2019-02-01 11:04:08.904 [main] INFO c.a.o.c.i.spring.support.PropertyPlaceholderConfigurer - Loading properties file from class path resource [example/instance.properties] 2019-02-01 11:04:09.349 [main] WARN o.s.beans.GenericTypeAwarePropertyDescriptor - Invalid JavaBean property 'connectionCharset' being accessed! Ambiguous write methods found next to actually used [public void com.alibaba.otter.canal.parse.inbound.mysql.AbstractMysqlEventParser.setConnectionCharset(java.lang.String)]: [public void com.alibaba.otter.canal.parse.inbound.mysql.AbstractMysqlEventParser.setConnectionCharset(java.nio.charset.Charset)] 2019-02-01 11:04:09.380 [main] INFO c.a.otter.canal.instance.spring.CanalInstanceWithSpring - start CannalInstance for 1-example 2019-02-01 11:04:09.400 [main] WARN c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table filter : ^...$ 2019-02-01 11:04:09.401 [main] WARN c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table black filter : 2019-02-01 11:04:09.412 [main] INFO c.a.otter.canal.instance.core.AbstractCanalInstance - start successful.... 2019-02-01 11:04:10.407 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> begin to find start position, it will be long time for reset or first position 2019-02-01 11:04:10.408 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - prepare to find start position just show master status 2019-02-01 11:04:10.495 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> find start position successfully, EntryPosition[included=false,journalName=bin-log.000004,position=154,serverId=,gtid=,timestamp=] cost : 26ms , the next step is binlog dump 2019-02-01 11:08:12.194 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.canal.parse.inbound.mysql.dbsync.DirectLogFetcher - Received EOF packet from server, apparent master disconnected. It's may be duplicate slaveId , check instance config 2019-02-01 11:08:27.068 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> begin to find start position, it will be long time for reset or first position 2019-02-01 11:08:27.088 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - prepare to find start position just show master status 2019-02-01 11:08:27.094 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> find start position successfully, EntryPosition[included=false,journalName=bin-log.000005,position=154,serverId=,gtid=,timestamp=] cost : 26ms , the next step is binlog dump 2019-02-01 11:14:47.318 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.canal.parse.inbound.mysql.dbsync.DirectLogFetcher - Received EOF packet from server, apparent master disconnected. It's may be duplicate slaveId , check instance config 2019-02-01 11:14:59.668 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> begin to find start position, it will be long time for reset or first position 2019-02-01 11:14:59.684 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - prepare to find start position just show master status 2019-02-01 11:14:59.687 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> find start position successfully, EntryPosition[included=false,journalName=bin-log.000006,position=154,serverId=,gtid=,timestamp=] cost : 18ms , the next step is binlog dump

原提问者GitHub用户GitGitGitWang

展开
收起
古拉古拉 2023-05-08 14:27:01 80 0
2 条回答
写回答
取消 提交回答
  • 确保运行canal-server机器cpu core数大于1

    原回答者GitHub用户agapple

    2023-05-09 18:00:17
    赞同 展开评论 打赏
  • 随心分享,欢迎友善交流讨论:)

    从日志中可以看出,Canal启动成功,但是在执行binlog dump操作时,出现了异常,导致Canal无法同步数据。具体原因可能包括:

    MySQL数据库出现异常或者断开连接,导致Canal无法获取binlog数据。

    Canal的配置文件中,binlog相关的配置参数设置不正确,导致无法正常获取binlog数据。

    Canal的版本与MySQL不兼容,出现兼容性问题。

    建议按照以下步骤进行排查:

    检查Canal的配置文件,确认binlog相关的配置参数是否正确,并且确保MySQL的binlog已经开启。

    检查MySQL数据库的状态,并且确认Canal所使用的MySQL账号是否有足够的权限。

    检查Canal的日志,查看是否有其他异常信息。

    如果以上方法无法解决问题,可以尝试升级Canal的版本,或者采用其他的数据同步方案,如使用MySQL自带的binlog同步功能。

    2023-05-08 14:46:31
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
DTCC 2022大会集锦《云原生一站式数据库技术与实践》 立即下载
阿里云瑶池数据库精要2022版 立即下载
2022 DTCC-阿里云一站式数据库上云最佳实践 立即下载