Canal部署运行问题记录

问题汇总

最近部署Canal遇到了不少问题，在此汇总一下遇到的和没遇到但较为常见的几个问题，更多是针对已经基本配置好Canal和数据库后运行中的错误，提供一些参考解决方案。

问题：数据同步时，接收到的entryType为ROWDATA的binlog，其eventType为QUERY，而不是期望的INSERT/UPDATE/DELETE

原因1： binlog模式为非Row模式。针对Statement/Mixed模式，DML语句都会以SQL语句存在。
解决1： 通过show variables like 'binlog_format'查看MySQL中binlog的模式，若为非Row模式则通过SET GLOBAL binlog_format = 'ROW';（全局设置，需重启后生效）和SET binlog_format = 'ROW';（当前设置，当无法重启服务时同时设置这两个参数）进行更改。

原因2： MySQL开启了binlog_rows_query_log_events。当这个设置开启后，MySQL不仅会将数据行级变化写入binlog，还会将执行数据变化的sql语句也写入到binlog中。观察eventType为QUERY的entry可以发现，订阅到的binlog中包含有SQL语句。
解决2： 通过show variables like 'binlog_rows%'查看binlog_rows_query_log_events是否为ON，若是的话则通过set global binlog_rows_query_log_events=off;（全局设置，需重启后生效）和set binlog_rows_query_log_events=off;（当前设置，当无法重启服务时同时设置这两个参数）关闭；或者可以通过更改canal.properties文件中的过滤配置来解决：canal.instance.filter.query.dml = true

问题：数据表过滤条件不生效，或只能接收到entryType为TRANSACTIONBEGIN和TRANSACTIONEND的entry，接收不到ROWDATA类型数据

原因1： Canal Server配置中canal.instance.filter.black.regex=.*\\..*
解决1： 更改canal.instance.filter.black.regex=后重启

原因2： Canal订阅配置有误
解决2：

1. 首先对照canal.instance.filter.regex的书写规范格式检查正则表达式：

多个正则之间以逗号(,)分隔，转义符需要双斜杠(\)
常见例子：

1. 所有表：.* or .\…
2. canal schema下所有表： canal\…*
3. canal下的以canal打头的表：canal\.canal.*
4. canal schema下的一张表：canal.test1
5. 多个规则组合使用：canal\…*,mysql.test1,mysql.test2 (逗号分隔)

2. 检查binlog是否为Row模式，非Row模式将不会解析sql，无法提取数据表名进行过滤。
3. 检查Canal客户端是否调用subscribe(filter)方法，若filter与canal.instance.filter.regex不一致，则会覆盖服务端配置。
4. 官方实例中都是使用如.*\\..*所示的双斜杠\\进行过滤配置，原意是需要一个\作为转义符，但这可能导致在不需要转义符的时候错误地过滤数据表。可通过Canal日志对比filter是否与期望的一致：

c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table filter : ^.*\..*$
c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table black filter :

特别注意： 在某些情况下（如binlog为非Row模式），当过滤配置生效后，除去TRANSACTIONBEGIN和TRANSACTIONEND，监听的表发生变更时会发送一个QUERY的entry和一个INSERT/UPDATE/DELETE的entry，而过滤的表变更时也会发送一个QUERY的entry，这并不代表过滤没有生效。我在关闭binlog_rows_query_log_events后没有再收到过其他数据库和数据表变更发送的QUERY日志。

问题：Could not find first log file name in binary log index file或Can’t find start position for example

原因： Canal是模拟从库，因此同样可能会出现主从数据库不一致的情况，具体表现为meta.dat中保存的位点信息和数据库的位点信息不一致，导致canal抓取不到数据库的动作。
解决： 删除meta.dat文件，再重启Canal，会自动重新生成正确的meta.dat文件。我在解决这个问题时只删除meta.dat并没有成功，删除meta.dat所在的整个文件夹后重启，问题解决。