Canal
# canal
阿里巴巴 B2B 公司，因为业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了同步杭州和美国异地机房的需求，从 2010 年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务。canal 是用 java 开发的基于数据库增量日志解析，提供增量数据订阅&消费的中间件。
目前，canal 主要支持了 MySQL 的 binlog 解析，解析完成后才利用 canal client 来处理获得的相关数据。（数据库同步需要阿里的 otter 中间件，基于 canal）。
# 使用场景
原始场景： 阿里 otter 中间件的一部分
otter 是阿里用于进行异地数据库之间的同步框架，canal 是其中一部分
常见场景1：更新缓存
抓取业务数据新增变化表，用于制作拉链表
常见场景3：抓取业务表的新增变化数据，用于制作实时统计（我们就是这种场景）
# canal 的工作原理
# MySQL 主从复制过程
- Master 主库将改变记录，写到二进制日志(binary log)中
- Slave 从库向 mysql master 发送 dump 协议，将 master 主库的 binary log events 拷贝到它的中继日志(relay log)；
- Slave 从库读取并重做中继日志中的事件，将改变的数据同步到自己的数据库。
# canal 的工作原理
很简单，就是把自己伪装成 slave，假装从 master 复制数据
# MySQL 的 binlog
MySQL 的二进制日志可以说 MySQL 最重要的日志了，它记录了所有的 DDL 和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
一般来说开启二进制日志大概会有 1%的性能损耗。二进制有两个最重要的使用场景:
- 其一：MySQL Replication 在 Master 端开启 binlog，Master 把它的二进制日志传递给 slaves 来达到 master-slave 数据一致的目的
- 其二：自然就是数据恢复了，通过使用 mysqlbinlog 工具来使恢复数据
二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的 DDL 和 DML(除了数据查询语句)语句事件。
# binlog 的开启
找到 MySQL 配置文件的位置 - my.cnf
linux： my.cnf windows: my.ini1
2
3在 mysql 的配置文件下,修改配置
在[mysqld] 区块，设置/添加 log-bin=mysql-bin
这 个 表 示 binlog 日 志 的 前 缀 是 mysql-bin ， 以 后 生 成 的 日 志 文 件 就 是mysql-bin.123456 的文件后面的数字按顺序生成，每次 mysql 重启或者到达单个文件大小的阈值时，新生一个文件，按顺序编号
binlog 的分类设置
mysql binlog 的格式有三种，分别是 STATEMENT,MIXED,ROW。
statement
语句级，binlog 会记录每次一执行写操作的语句。相对 row 模式节省空间，但是可能产生不一致性，比如
update tt set create_date=now()如果用 binlog 日志进行恢复，由于执行时间不同可能产生的数据就不同。优点： 节省空间 缺点： 有可能造成数据不一致。
row
行级， binlog 会记录每次操作后每行记录的变化
优点：保持数据的绝对一致性。因为不管 sql 是什么，引用了什么函数，他只记录执行后的效果。
缺点：占用较大空间
mixed
statement 的升级版，一定程度上解决了，因为一些情况而造成的 statement 模式不一致问题
默认还是 statement，在某些情况下譬如:
当函数中包含 UUID() 时； 包含 AUTO_INCREMENT 字段的表被更新时； 执行 INSERT DELAYED 语句时； 用 UDF 时；
会按照 ROW 的方式进行处理 优点：节省空间，同时兼顾了一定的一致性。 缺点：还有些极个别情况依旧会造成不一致，另外 statement 和 mixed 对于需要对 binlog 的监控的情况都不方便。
综合上面对比，Cannel 想做监控分析，选择 row 格式比较合适
# MySQL 的准备
创建实时业务数据库 gmall2020导入建表数据
修改/etc/my.cnf 文件
server-id= 1 log-bin=mysql-bin binlog_format=row binlog-do-db=gmall20201
2
3
4注意：binlog-do-db 根据自己的情况进行修改，指定具体要同步的数据库
重启 MySQL 使配置生效
测试 - 添加数据查看bin-log文件大小
mysql创建canal用户供外部访问
mysql> set global validate_password_length=4; mysql> set global validate_password_policy=0; mysql> GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO'canal'@'%' IDENTIFIED BY 'canal' ;1
2
3
# canal 架构以及安装
# canal 架构
# canal 的下载和安装
https://github.com/alibaba/canal/releases
# canal单机版
上传解压文件
注意：canal解压后是散的，我们在指定解压目录的时候需要将canal指定上
mkdir /opt/module/canal tar -zxvf canal.deployer-1.1.4.tar.gz -C /opt/module/canal1
2修改配置文件 - canal.properties
这个文件是 canal 的基本通用配置，canal 端口号默认就是 11111
修改 canal 的输出 model，默认 tcp，改为输出到 kafka1
tcp 就是输出到 canal 客户端，通过编写 Java 代码处理
修改 Kafka 集群的地址
如果创建多个实例
通过前面 canal 架构，我们可以知道，一个 canal 服务中可以有多个 instance，conf/下的每一个 example 即是一个实例，每个实例下面都有独立的配置文件。默认只有一个实例 example，如果需要多个实例处理不同的 MySQL 数据的话，直接拷贝出多个 example，并对其重新命名，命名和配置文件中指定的名称一致，然后修改 canal.properties 中的canal.destinations=实例 1，实例 2，实例 3。
修改 instance.properties
我们这里只读取一个 MySQL 数据，所以只有一个实例，这个实例的配置文件在conf/example 目录下
vim instance.properties
配置 MySQL 服务器地址
配置连接 MySQL 的用户名和密码，默认就是我们前面授权的 canal
修改输出到 Kafka 的主题以及分区数
注意：默认还是输出到指定 Kafka 主题的一个 kafka 分区，因为多个分区并行可能会打乱binlog 的顺序 如果要提高并行度，首先设置 kafka 的分区数>1,然后设置 canal.mq.partitionHash 属性
单机 canal 测试
启动 canal
bin/startup.sh1看到 CanalLauncher 你表示启动成功，同时会创建 gmall2020_db_c 主题
启动 Kafka 消费客户端测试，查看消费情况
bin/kafka-console-consumer.sh --bootstrap-server ha01:9092 --topic gmall2020_db_c1运行/opt/module/rt_dblog 中生成模拟数据
查看kafka消息
# canal 高可用（了解）
这种 zookeeper 为观察者监控的模式，只能实现高可用，而不是负载均衡，即同一时点只有一个 canal-server 节点能够监控某个数据源，只要这个节点能够正常工作，那么其他监控这个数据源的 canal-server 只能做 stand-by，直到工作节点停掉，其他 canal-server 节点才能抢占。因为有一个 stand-by 也要占用资源，同时 canal 传输数据宕机的情况也比较少，所以好多企业是不配置 canal 的高可用的。
修改 canal.properties
配置zk
避免发送重复数据（否则在切换 active 的时候会重复发送数据）
把 canal 目录分发给其他虚拟机
启动
先在ha01启动 canal，再在 ha02 上启动 canal