环境信息
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
从日志中可以看出,Canal启动成功,但是在执行binlog dump操作时,出现了异常,导致Canal无法同步数据。具体原因可能包括:
MySQL数据库出现异常或者断开连接,导致Canal无法获取binlog数据。
Canal的配置文件中,binlog相关的配置参数设置不正确,导致无法正常获取binlog数据。
Canal的版本与MySQL不兼容,出现兼容性问题。
建议按照以下步骤进行排查:
检查Canal的配置文件,确认binlog相关的配置参数是否正确,并且确保MySQL的binlog已经开启。
检查MySQL数据库的状态,并且确认Canal所使用的MySQL账号是否有足够的权限。
检查Canal的日志,查看是否有其他异常信息。
如果以上方法无法解决问题,可以尝试升级Canal的版本,或者采用其他的数据同步方案,如使用MySQL自带的binlog同步功能。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。