一. 阿里 canal 工作原理
canal 是阿里的一款开源我的项目,纯 Java 开发。基于数据库增量日志解析,提供增量数据订阅 & 生产,目前次要反对了 MySQL(也反对 mariaDB)。
MySQL 主备复制原理
- Master 将变更写入 binlog 日志;
- Slave 的 I/O thread 会去申请 Master 的 binlog,并将失去的 binlog 写到本地的 relay-log(中继日志)文件中;
- Slave 的 SQL thread 会从中继日志读取 binlog,而后执行 binlog 日志中的内容,也就是在本人本地再次执行一遍 SQL 语句,从而使从服务器和主服务器的数据保持一致。
更多
MySQL 的 Binary Log 介绍
- http://dev.mysql.com/doc/refman/5.5/en/binary-log.html
- http://www.taobaodba.com/html/474_mysqls-binary-log_details.html
canal 的工作原理
- canal 模仿 mysql slave 的交互协定,假装本人为 mysql slave,向 mysql master 发送 dump 协定;
- mysql master 收到 dump 申请,开始推送 binary log 给 slave(也就是 canal)
- canal 解析 binary log 对象(原始为 byte 流)。
更多
对于 canal 的具体介绍,能够拜访官网:https://github.com/alibaba/canal
二. 阿里 canal 的 HA 机制
1. 什么是 HA 机制
所谓 HA(High Available),即高可用(7*24 小时不中断服务)。
2. 单点故障
实现高可用最要害的策略是打消单点故障。比方 Hadoop2.0 之前,在 HDFS 集群中 NameNode 存在单点故障:
- NameNode 机器发生意外,如宕机,集群将无奈应用;
- NameNode 机器须要降级,包含软件、硬件降级,此时集群也将无奈应用。
3. Hadoop2.0 引入 HA 机制
通过配置 Active/Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。
- 有一台节点是 Active 模式,也就是工作模式,其它的节点是 Standby(备用模式);
- 干活的(Active 模式的节点)如果挂了,就从备用模式的节点中选出一台顶上去。
更多
对于 Hadoop 的 HA 机制的具体介绍,能够拜访:https://blog.csdn.net/pengjunlee/article/details/81583052
4. zookeeper 的 watcher 和 EPHEMERAL 节点
zookeeper 的 watcher
watcher 机制波及到客户端与服务器(留神,不止一个机器,个别是集群)的两者数据通信与音讯通信:
更多
对于 watcher 的具体介绍,能够拜访:https://www.jianshu.com/p/4c071e963f18
zookeeper 的节点类型
EPHEMERAL 节点是 zookeeper 的长期节点,长期节点与 session 生命周期绑定,客户端会话生效后长期节点会主动革除。
更多
对于 zookeeper EPHEMERAL 节点的具体介绍,能够拜访:
https://blog.csdn.net/randompeople/article/details/70500076
5. canal 的 HA 机制
整个 HA 机制的管制次要是依赖了 zookeeper 的上述两个个性:watcher、EPHEMERAL 节点。canal 的 HA 机制实现分为两局部,canal server 和 canal client 别离有对应的实现。
canal server 实现流程
- canal server 要启动某个 canal instance 时都先向 zookeeper 进行一次尝试启动判断 (实现:创立 EPHEMERAL 节点,谁创立胜利就容许谁启动);
- 创立 zookeeper 节点胜利后,对应的 canal server 就启动对应的 canal instance,没有创立胜利的 canal instance 就会处于 standby 状态;
- 一旦 zookeeper 发现 canal server A 创立的节点隐没后,立刻告诉其余的 canal server 再次进行步骤 1 的操作,从新选出一个 canal server 启动 instance;
- canal client 每次进行 connect 时,会首先向 zookeeper 询问以后是谁启动了 canal instance,而后和其建设链接,一旦链接不可用,会从新尝试 connect。
留神
为了缩小对 mysql dump 的申请,不同 server 上的 instance 要求同一时间只能有一个处于 running,其余的处于 standby 状态。
canal client 实现流程
- canal client 的形式和 canal server 形式相似,也是利用 zookeeper 的抢占 EPHEMERAL 节点的形式进行管制
- 为了保障有序性,一份 instance 同一时间只能由一个 canal client 进行 get/ack/rollback 操作,否则客户端接管无奈保障有序。
三. canal 的 HA 集群模式部署
1. canal 下载地址
- 下载地址:https://github.com/alibaba/canal/releases
我应用的是 1.1.4 稳固版本。
2. mysql 开启 binlog
MySQL , 须要先开启 Binlog 写入性能,配置 binlog-format 为 ROW 模式,my.cnf 中配置如下:
[mysqld]
log-bin=mysql-bin # 开启 binlog
binlog-format=ROW # 抉择 ROW 模式
server_id=1 # 配置 MySQL replaction 须要定义,不要和 canal 的 slaveId 反复
3. mysql 受权账号权限
受权 canal 链接 MySQL 账号具备作为 MySQL slave 的权限, 如果已有账户可间接 grant:
CREATE USER canal IDENTIFIED BY 'canal';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
-- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;
FLUSH PRIVILEGES;
备注
能够通过在 mysql 终端中执行以下命令判断配置是否失效:
show variables like 'log_bin';
show variables like 'binlog_format';
4. 批改配置
canal 服务的部署其实特地简略,解压之后只需批改 canal.properties、instance.properties
这两个配置两个文件即可。
批改 canal.properties 中配置
// 指定注册的 zk 集群地址
canal.zkServers =127.0.0.1:2181,127.0.0.2:2181
//HA 模式必须应用该 xml,须要将相干数据写入 zookeeper, 保证数据集群共享
canal.instance.global.spring.xml = classpath:spring/default-instance.xml
// 这个 demo 就是 conf 目录里的实例,如果要建别的实例 'test' 就建个 test 目录,把 example 外面的 instance.properties 文件拷贝到 test 的实例目录下就好了,而后在这里的配置就是 canal.destinations = demo,test
canal.destinations = demo
批改 demo.properties 中配置
## mysql serverId , v1.0.26+ will autoGen
# canal 假装的 mysql slave 的编号,不能与 mysql 数据库和其余的 slave 反复
canal.instance.mysql.slaveId=1003
# 按需批改成本人的数据库信息
# position info
canal.instance.master.address=10.200.*.109:3306
# username/password 数据库的用户名和明码
canal.instance.dbUsername=canal
canal.instance.dbPassword=canal
canal.instance.defaultDatabaseName = test
5. 具体步骤
canal 的 HA 集群模式部署具体步骤,能够拜访:https://blog.csdn.net/XDSXHDYY/article/details/97825508
四. 通过实例感触 zookeeper 在 HA 机制中的作用
说了这么多,上面通过一个实例演示来感受一下 zookeeper 到底起了什么作用。
新建一个叫 ‘demo’ 的实例:
$ cd /data/application/canal.deployer-1.1.4/conf
$ cp -r example demo
配置文件的批改能够参考 第三局部 贴出的配置。
环境
1. 版本
canal(1.1.4) + Zookeeper(3.4.6-78--1)
2. canal 集群
canal server 部署在两台机器上:
10.200.*.108 和 10.200.*.109
3. zookeeper 集群
zookeeper 部署在三台机器上:
10.200.*.109:2181,10.200.*.110:2181,10.200.*.111:2181
从 zookeeper 中查看 active 节点信息
1. 应用 zkClient 链接 zookeeper server
$ ./zkCli.sh -server localhost:2181
2. 查看 zookeeper 集群中,canal server 的 active 节点信息
[zk: localhost:2181(CONNECTED) 3] get /otter/canal/destinations/demo/running
因为我还没有启动任何一台 canal server,所以查问的节点不存在。
别离启动多台机器上的 canal server
别离登陆 108 和 109 两台机器,cd 到 canal 所在目录,命令行启动服务:
cd /data/application/canal.deployer-1.1.4
sh bin/startup.sh
景象一:只会有一个 canal server 的 demo(instance 名称)处于 active 状态
1. 持续查看 zookeeper 集群中,canal server 的 active 节点信息
从图中能够看出:
- 当前工作的节点为:10.200.*.109:11111。
2. 别离查看 canal server 的 启动日志
通过去 109 和 108 这两台机器上找到 canal server 启动日志,去验证一下下面的论断。
- 查看 109 机器的 canal server 启动日志:
[root@dc23x109-jiqi canal.deployer-1.1.4]# tail -f logs/demo/demo.log
- 查看 108 机器的 canal server 启动日志:
从图中能够看出:
- 该 log 目录上面没有 demo 目录,也就是说 108 机器上的 canal server 压根没有产生启动日志。
3. 论断
通过从 zookeeper 中查看节点信息和别离从两台 canal server 所在的机器上查看日志,能够得出如下论断:
- 109 和 108 上的 canal server 在接到
sh startup.sh
命令后,都向 zookeeper 尝试创立 EPHEMERAL 节点,109 的 canal server 创立胜利,因而启动的 demo 实例就处于 active 状态; - 108 机器上的 canal server 创立 EPHEMERAL 节点失败,因而该 server 的 demo 实例就处于 standby 状态。
- 雷同名称的实例在散布在多个机器上的多个 server 里,同一时刻只会有一个实例处于 active 状态,缩小对 mysql master dump 的申请。
景象二:敞开一个 canal server 后会从新选出一个 canal server
1. 手动敞开 109 机器的 canal server
cd /data/application/canal.deployer-1.1.4
sh bin/stop.sh
2. 查看 zookeeper 集群中,canal server 的 active 节点信息
从图中能够看出:
- 以后可用的 canal server 切换为:10.200.*.109:11111。
3. 论断
- 再次验证,canal server 启动时向 zookeeper 创立的节点就是 长期节点 , 它与 session 生命周期绑定,当我手动执行敞开命令,客户端会话会生效,长期节点会主动革除;
- 一旦 zookeeper 发现 canal server 108 机器创立的节点隐没后,就会告诉其它的 canal server 再次进行向 zookeeper 尝试创立长期节点的操作,就会有新的 active 节点产生;
- 这不就是 HA 机制最外围的作用嘛,一个机器机器发生意外,如宕机,另外一个机器可能立马顶上,保障集群的失常应用,从而保障服务的高可用。
关注微信公众号
欢送大家关注我的微信公众号浏览更多文章: