canal消耗内存_阿里巴巴Canal常见问题：重复解析/Filter失效/消费落后

前言

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模式下，由于他是记录的执行语句，所以，为了让这些语句在