canal入门

1. canal简介

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费。当前的canal中间件支持源端MySQL的版本包括 5.1.x，5.5.x，5.6.x，5.7.x，8.0.x。

2. MySQL的Binlog

MySQL 的二进制日志记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。开启binlog日志大概会有1%的性能损耗。主要有两个最重要的使用场景:

1. MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给Slaves来达到Master-Slave数据一致的目的。
2. 自然就是数据恢复了，通过使用MySQL binlog工具来使恢复数据。

binlog含有两类文件：

• binlog日志索引文件(文件名后缀为.index)用于记录所有的二进制文件。
• binlog日志文件(文件名后缀为.00000*)记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

3. Binlog的分类

MySQL Binlog的格式有三种，分别是STATEMENT,MIXED,ROW。在配置文件中可以选择配置binlog_format=statement|mixed|row。

3.1 statement格式

语句级日志，binlog 会记录每次一执行写操作的语句。相对row格式节省空间，但是可能产生不一致性，比如"update tt set create_date=now()"，如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。
优点：节省空间。
缺点：有可能造成数据不一致。

3.2 row格式

行级日志， binlog会记录每次操作后每行记录的变化。
优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。
缺点：占用较大空间。

3.3 mixed格式

statement格式的升级版，一定程度上解决了，因为一些情况而造成的statement格式不一致问题，默认还是statement，在某些情况下譬如：当函数中包含UUID()时；包含AUTO_INCREMENT字段的表被更新时；执行INSERT DELAYED语句时；用UDF时；会按照ROW的方式进行处理。
优点：节省空间，同时兼顾了一定的一致性。
缺点：还有些极个别情况依旧会造成不一致，另外statement和mixed对于需要对binlog的监控的情况都不方便。

综合上面对比，canal想做监控分析，选择row格式比较合适。

4. MySQL主从复制

1. Master主库将改变记录，写到二进制日志(Binary Log)中；
2. Slave从库向MySQL Master发送dump协议，将Master主库的binary log events拷贝到它的中继日志(relay log)；
3. Slave从库读取并重做中继日志中的事件，将改变的数据同步到自己的数据库。

5. canal工作原理

• canal模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议
• MySQL master收到dump请求，开始推送binary log给slave(即canal)
• canal解析binary log对象(原始为byte流)

6. canal架构

说明：

• server代表一个canal运行实例，对应于一个jvm
• instance对应于一个数据队列(1个server对应1..n个instance)

instance模块：

• eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
• eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
• eventStore (数据存储)
• metaManager (增量订阅&消费信息管理器)