一、Canal的HA机制

整个HA机制的控制主要是依赖了zookeeper的上述两个特性：watcher、EPHEMERAL节点。canal的HA机制实现分为两部分，Canal server和Canal client分别有对应的实现。

image.png
1、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 上的instacne要求同一时间只能有一个处于running，其他的处于standby状态

2、canal client 实现流程

  • canal client的方式和canal server 方式类似，也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制
  • 为了保证有序性，一份instance同一时间只能由一个canal client 进行get/ack/rollback操作，否则客户端无法保证有序性

二、通过实例感受zookeeper在HA机制中的作用

说了这么多，下面通过一个实例演示来感受一下 zookeeper 到底起了什么作用。
新建一个叫 ‘demo’ 的实例：
$ cd /data/application/canal.deployer-1.1.4/conf $ cp -r example demo
配置文件的修改可以参考第三部分贴出的配置。

1、环境

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

2、从 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
image.png
由于我还没有启动任何一台 canal server，所以查询的节点不存在。

3、分别启动多台机器上的canal server

分别登陆 108 和 109 两台机器，cd 到 canal 所在目录，命令行启动服务：
cd /data/application/canal.deployer-1.1.4
sh bin/startup.sh

4、HA高可用现象

现象一： 只会有一个canal server的demo(instance名称)处于active状态

1、继续查看zookeeper集群中，canal server的active节点信息
image.png
从图中可以看出：

  • 当前工作的节点为: 10.200.*。109:1111

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 启动日志：
    image.png

从图中可以看出：
该log目录下面没有 demo目录，也就是说 108 机器上的 canal server 压根没有产生启动日志。

3、结论
通过从zookeeper中查看节点信息和分别从两台canal server 所在的机器上查看日志，可以得出如下结论：

  • 109和108上的canal server 在接到sh startup.sh 命令后，都向zookeeper尝试创建EPHEMRAL节点，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节点信息

    image.png
    从图中可以看出：

  • 当前可用的 canal server 切换为：10.200.*.109:11111。

3、结论
1、再次验证，canal server启动时向zookeeper创建的节点就是临时节点，它与session生命周期绑定，当手动执行关闭命令，客户段会话会失效，临时节点会自动清除
2、一旦zookeeper发现当前 active 的canal server 创建的节点消失后，就会通知其它的canal server 再次进行向zookeeper尝试创建临时节点的操作，就会有新的active节点产生
3、这就是HA机制最核心的作用，一个机器发生意外，如宕机，另外一个机器能够立马顶上，保证集群的正常使用，从而保证服务的高可用

https://segmentfault.com/a/1190000023297973