mysql otter canal_Canal部署踩坑记

Canal是什么

canal主要用途是基于 MySQL 数据库增量日志(binlog)解析，提供增量数据订阅和消费

Canal有什么用

image.png实时更新ES索引，减少业务系统与ES的耦合

端到端的核对，比如营销场景，可通过binlog的订阅对发奖与支付做核对，跳过业务链路的中间环节，即时发现链路中的bug

数据同步，备份等

缓存刷新

……

Canal部署时遇到的坑

本地OK测试/生产环境连不上数据库

连接本地mysql时没问题，但连测试环境时出现连不上数据库的异常，本地通过命令行能连上测试环境数据库，异常如下：

java.io.IOException: ErrorPacket [errorNumber=2003, fieldCount=-1, message=Can't connect to MySQL server on '(这里去掉了ip)' (107), sqlState=HY000, sqlStateMarker=#]

with command: set @master_binlog_checksum= @@global.binlog_checksum

at com.alibaba.otter.canal.parse.driver.mysql.MysqlUpdateExecutor.update(MysqlUpdateExecutor.java:49) ~[canal.parse.driver-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlConnection.update(MysqlConnection.java:116) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlConnection.updateSettings(MysqlConnection.java:420) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlConnection.seek(MysqlConnection.java:123) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser.findAsPerTimestampInSpecificLogFile(MysqlEventParser.java:746) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser.findEndPositionWithMasterIdAndTimestamp(MysqlEventParser.java:395) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser.findStartPositionInternal(MysqlEventParser.java:450) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser.findStartPosition(MysqlEventParser.java:369) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at com.alibaba.otter.canal.parse.inbound.AbstractEventParser$3.run(AbstractEventParser.java:194) [canal.parse-1.1.5-SNAPSHOT.jar:na]

at java.lang.Thread.run(Unknown Source) [na:1.8.0_161]原因：没有直连mysql导致，连了ProxySQL

解决方案：直连mysql即可

同步到的binlog是QUERY类型

同步到的binlog的eventType为QUERY，而不是我们认为的INSERT/UPDATE/DELETE这三种，且entryType为ROWDATA原因：mysql开启了binlog_rows_query_log_events，通过命令

show variables like 'binlog_rows%'

可以看到binlog_rows_query_log_events的值，如果为ON，则Mysql不仅会写入数据更新的binlog，还会将执行更新的sql语句也写入到binlog中，订阅到的eventType为QUERY的binlog则是写入到binlog中的SQL语句解决方案：如果需要订阅eventType=QUERY的，则不需要将链路走通即可，不需要做其它处理

如果不需要这类binlog，将canal.properties文件中的以下过虑配置成true即可canal.instance.filter.query.dml = true