乐趣区

关于canal:阿里canal是怎么通过zookeeper实现HA机制的

一. 阿里 canal 工作原理

canal 是阿里的一款开源我的项目,纯 Java 开发。基于数据库增量日志解析,提供增量数据订阅 & 生产,目前次要反对了 MySQL(也反对 mariaDB)。

MySQL 主备复制原理

  1. Master 将变更写入 binlog 日志;
  2. Slave 的 I/O thread 会去申请 Master 的 binlog,并将失去的 binlog 写到本地的 relay-log(中继日志)文件中;
  3. 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 的工作原理

  1. canal 模仿 mysql slave 的交互协定,假装本人为 mysql slave,向 mysql master 发送 dump 协定;
  2. mysql master 收到 dump 申请,开始推送 binary log 给 slave(也就是 canal)
  3. canal 解析 binary log 对象(原始为 byte 流)。
更多

对于 canal 的具体介绍,能够拜访官网:https://github.com/alibaba/canal

二. 阿里 canal 的 HA 机制

1. 什么是 HA 机制

所谓 HA(High Available),即高可用(7*24 小时不中断服务)。

2. 单点故障

实现高可用最要害的策略是打消单点故障。比方 Hadoop2.0 之前,在 HDFS 集群中 NameNode 存在单点故障:

  1. NameNode 机器发生意外,如宕机,集群将无奈应用;
  2. 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 实现流程
  1. canal server 要启动某个 canal instance 时都先向 zookeeper 进行一次尝试启动判断 (实现:创立 EPHEMERAL 节点,谁创立胜利就容许谁启动);
  2. 创立 zookeeper 节点胜利后,对应的 canal server 就启动对应的 canal instance,没有创立胜利的 canal instance 就会处于 standby 状态;
  3. 一旦 zookeeper 发现 canal server A 创立的节点隐没后,立刻告诉其余的 canal server 再次进行步骤 1 的操作,从新选出一个 canal server 启动 instance;
  4. 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. 论断
  1. 再次验证,canal server 启动时向 zookeeper 创立的节点就是 长期节点 它与 session 生命周期绑定,当我手动执行敞开命令,客户端会话会生效,长期节点会主动革除
  2. 一旦 zookeeper 发现 canal server 108 机器创立的节点隐没后,就会告诉其它的 canal server 再次进行向 zookeeper 尝试创立长期节点的操作,就会有新的 active 节点产生
  3. 这不就是 HA 机制最外围的作用嘛,一个机器机器发生意外,如宕机,另外一个机器可能立马顶上,保障集群的失常应用,从而保障服务的高可用。

关注微信公众号

欢送大家关注我的微信公众号浏览更多文章:

退出移动版