前言
Canal是阿里巴巴开源的数据库Binlog日志解析框架,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。
在之前我写的文章阿里开源MySQL中间件Canal快速入门中,我已经介绍了Canal的基本原理和基础使用。
在部署到生产环境的过程中,自己作为一个菜鸟,又踩了一些坑,期间做了记录和总结,并再解决后分析了下原因,便有了此文。
本文重点内容
Canal常见的三大问题原因分析及解决方案
Binlog解析错误:重复解析/DML解析为QUERY
Filter失效:设置过滤器无效
消费落后:消费延迟或卡死
Canal踩坑与原因分析
问题:Binlog解析错误 重复解析/DML解析为QUERY
这个问题主要由以下几种典型情况:
INSERT/UPDATE/DELETE被解析为Query或DDL语句
Binlog重复解析,即一个操作又有QUERY消息,又有对应的INSERT/UPDATE/DELETE消息。
这两个问题主要都是因为Binlog不是row模式导致的,先来复习下Binlog的三种模式。
复习 MySQL Binlog的三种运行模式
MySQL在进行主从同步时,会使用Binlog,从库读取Binlog来进行数据的同步。但是Binlog是有三种不同的运行模式的,分别是ROW模式、Statement模式和Mix模式。
1. ROW模式
Binlog日志中仅记录哪一条记录被修改了,修改成什么样了,会非常清楚的记录下每一行数据修改的细节,Master修改了哪些行,slave也直接修改对应行的数据
优点:row的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程和function,以及trigger的调用和出发无法被正确复制问题。
缺点:在row模式下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容。
2. Statement模式
每一条会修改数据的sql都会记录到master的binlog中,slave在复制的时候sql进程会解析成和原来master端执行相同的sql再执行。
优点:在statement模式下首先就是解决了row模式的缺点,不需要记录每一行数据的变化减少了binlog日志量,节省了I/O以及存储资源,提高性能。因为他只需要记录在master上所执行的语句的细节以及执行语句的上下文信息。
缺点:在statement模式下,由于他是记录的执行语句,所以,为了让这些语句在