其他配置项可以按需修改。「对于canal.properties，Canal多个集群节点可以完全一致，写好一份然后拷贝使用即可」。接着可以分别启动两个Canal服务，一般来说，先启动的节点会成为running节点：
Linux下的启动日志（example.log）：
Windows下的启动日志（canal.log）：
测试Canal高可用集群
先启动虚拟机中的Canal服务，再启动本地开发机中的Canal服务：
可见当前的cluster列表中包含了两个host:port，而running节点中的信息只包含虚拟机的host:port，意味着当前运行节点时虚拟机中的Canal服务，本地开发机中的Canal服务作为备用节点。此时可以尝试在虚拟机中执行sh stop.sh关闭Canal服务：
可见cluster列表只剩下本地开发机中的Canal服务的host:port，而running节点中的信息也是指向此服务信息。至此「成功验证了Canal主备模式」的切换。此时可以再验证一下开发机中的example.log：
说说Canal保存在Zookeeper中的数据节点
前文使用ZooInspector展示了Canal保存在Zookeeper中的节点信息，这里简单分析一下。节点树的结构如下：
/otter/canal/cluster路径的展开如下：
# 其实就是挂载了所有集群节点的host:port信息
/otter/canal/cluster
- 192.168.56.1:11111
- 172.17.0.1:11111
/otter/canal/destinations路径会相对复杂，展开的信息如下：
/otter/canal/destinations
- Instance标识
- running 记录当前为此Instance提供服务状态为running的Canal节点 [EPHEMERAL类型]
- cluster 记录当前为此Instance提供服务的Canal集群节点列表
- Client序号标识
- running 客户端当前正在读取的running节点 [EPHEMERAL类型]
- cluster 记录当前读取此Instance的客户端节点列表
- cursor 记录客户端读取的position信息
# 例如
/otter/canal/destinations
- example
- running -> {"active":true,"address":"192.168.56.1:11111"}
- cluster
- 192.168.56.1:11111
- 172.17.0.1:11111
- 1001
- running
- cluster
- cursor
理解各个路径存放的信息，有利于在Canal集群出现故障的时候结合日志进行故障排查。
小结
Canal集群已经在生产跑了一段时间，大部分的问题和坑都已经遇到过，有些问题通过了屏蔽某些开关解决，一些遗留无法解决的问题也想办法通过预警手段人工介入处理。Canal的HA其实是比较典型的主备模式，也就是同一个时刻，只有单个Canal服务对单个Instance（Destination）进行处理，想了下确实好像这样才能确保主备中继日志同步的基本有序，备用节点其实是完全划水不工作的（除了监听Zookeeper中的路径变更），一旦running节点出现故障或者宕机，备用节点就会提升为running节点，确保集群的可用性。
（本文完 c-3-d e-a-20200822 封面来源于动漫《可塑性记忆》）
本文分享自微信公众号 - Throwable文摘（throwable-doge）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。