Canal部署运行问题记录

Canal部署运行问题记录,第1张

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 (逗号分隔)
  1. 检查binlog是否为Row模式,非Row模式将不会解析sql,无法提取数据表名进行过滤。
  2. 检查Canal客户端是否调用subscribe(filter)方法,若filter与canal.instance.filter.regex不一致,则会覆盖服务端配置。
  3. 官方实例中都是使用如.*\..*所示的双斜杠\进行过滤配置,原意是需要一个作为转义符,但这可能导致在不需要转义符的时候错误地过滤数据表。可通过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所在的整个文件夹后重启,问题解决。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5605620.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-15
下一篇 2022-12-15

发表评论

登录后才能评论

评论列表(0条)

保存