阿里巴巴Canal实战

 上篇文章讲述了Canal的组成部分以及工作原理，包括使用场景，本文主要从CanalServer的部署，CanalClient客户端的订阅消费等方面实战，更好的记录工作中如何使用Canal的。

 

一：环境要求

机器	应用
192.168.111.128	mysql、zookeeper、kafka
192.168.111.130	mysql、zookeeper、kafka、kafka-eagle
192.168.111.131	mysql、zookeeper、kafka、zkUi

在进行canal实战之前，需要依赖一些基础环境的安装，如 mysql安装、kafka集群安装、zookeeper集群安装、zk管理端zkUI的安装、kafka管理端kafka-eagle安装，本文这里不在描述，可以参考对应的链接进行安装

 

Mysql要求

 a. 当前的canal开源版本支持5.7及以下的版本(阿里内部mysql 5.7.13, 5.6.10, mysql 5.5.18和5.1.40/48)，ps. mysql4.x版本没有经过严格测试，理论上是可以兼容

 b. canal的原理是基于mysql binlog技术，所以这里一定需要开启mysql的binlog写入功能，并且配置binlog模式为row.

[mysqld]  
log-bin=mysql-bin #添加这一行就ok  
binlog-format=ROW #选择row模式  
server_id=1 #配置mysql replaction需要定义，不能和canal的slaveId重复 

MySQL binlog日志格式有  Row、Statement、Mixed三种

1. Row

日志中会记录成每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改

优点：row 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程或 function ，以及 trigger 的调用和触发无法被正确复制的问题。

缺点：在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容

2. Statement

每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。

优点：在 statement 模式下，首先就是解决了 row 模式的缺点，不需要记录每一行数据的变化，减少了 bin-log 日志量，节省 I/O 以及存储资源，提高性能。因为他只需要记录在 master 上所执行的语句的细节，以及执行语句时候的上下文的信息。

缺点：在 statement 模式下，由于他是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果；在 statement 中，目前已经发现的就有不少情况会造成 MySQL 的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现。

3. Mixed

从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。

新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

 c.数据库重启后, 简单测试 my.cnf 配置是否生效:

mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+

  d.  canal的原理是模拟自己为mysql slave，所以这里一定需要做为mysql slave的相关权限 

CREATE USER canal IDENTIFIED BY 'root';    
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'root'@'%';  
-- GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' ;  
FLUSH PRIVILEGES; 

二：CanalServer部署

1、下载

目前最新的版本是1.1.5，点击此处进行管网下载对应的版本

下载好后上传到对应的服务器上（192.168.111.128），并解压好。

进入conf目录下

 canal_local.properties：在使用canalAdmin时，只需配置此配置文件即可，在下篇文件讲解

 canal.properties：canalServer的配置文件

 example：默认的instance目录，可以自定义，例如 example1 example2 

                instance.properties:每个instance对应的配置文件，主要配置数据库连接信息
 spring：canal组件的配置定义，具体说明可见上篇文章中的配置信息

2、配置

canal.properties介绍：

1.   instance列表定义 (列出当前server上有多少个instance，每个instance的加载方式是spring/manager等)

<

参数名字	参数说明	默认值
canal.destinations	当前server上部署的instance列表	无
canal.conf.dir	conf/目录所在的路径	../conf
canal.auto.scan	开启instance自动扫描 如果配置为true，canal.conf.dir目录下的instance配置变化会自动触发： a. instance目录新增： 触发instance配置载入，lazy为true时则自动启动 b. instance目录删除：卸载对应instance配置，如已启动则进行关闭 c. instance.properties文件变化：reload instance配置，如已启动自动进行重启操作	true
canal.auto.scan.interval	instance自动扫描的间隔时间，单位秒	5
canal.instance.global.mode	全局配置加载方式	spring
canal.instance.global.lazy	全局lazy模式	false
canal.instance.global.manager.address	全局的manager配置方式的链接信息	无