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

48次阅读

共计 5325 个字符，预计需要花费 14 分钟才能阅读完成。

一. 阿里 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 机制最外围的作用嘛，一个机器机器发生意外，如宕机，另外一个机器可能立马顶上，保障集群的失常应用，从而保障服务的高可用。

关注微信公众号

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

正文完
canal
发表至： canal
2020-07-20
 0
关于canal:Canal-adapter-同步-ElasticSearch-记录
关于canal:canal探究
关于canal:How-old-are-you-尚硅谷大数据之Canal视频教程发布
关于canal:移山数据迁移平台实时数据同步服务的架构设计