canal服務端HA模式，本人並未使用過，為保證文章的完整性，從以下地址摘抄該部分內容，待以後驗證及使用

https://github.com/alibaba/canal/wiki/AdminGuide

1、機器準備

① 2個canal服務端節點 10.20.144.22, 10.20.144.51

② zookeeper地址為10.20.144.51:2181

③ mysql地址：10.20.144.15:3306

2、按照部署和配置，在單臺機器上各自完成配置，演示時instance name為example

① 修改canal.properties，加上zookeeper配置，spring配置選擇default-instance.xml

1 canal.zkServers=10.20.144.51:2181
2 canal.instance.global.spring.xml = classpath:spring/default-instance.xml

② 創建example目錄，並修改instance.properties

1 canal.instance.mysql.slaveId = 1234 ##另外一臺機器改成1235，保證slaveId不重復即可
2 canal.instance.master.address = 10.20.144.15:3306

註意： 兩臺機器上的instance目錄的名字需要保證完全一致，HA模式是依賴於instance name進行管理，同時必須都選擇default-instance.xml配置

3、啟動兩臺機器的canal

啟動後，你可以查看logs/example/example.log，只會看到一臺機器上出現了啟動成功的日誌。

查看一下zookeeper中的節點信息，也可以知道當前工作的節點為10.20.144.51:11111

1 [zk: localhost:2181(CONNECTED) 15] get /otter/canal/destinations/example/running  
2 {"active":true,"address":"10.20.144.51:11111","cid":1}

4、客戶端鏈接, 消費數據

可以直接指定zookeeper地址和instance name，canal client會自動從zookeeper中的running節點，獲取當前服務的工作節點，然後與其建立鏈接：

1 CanalConnector connector = CanalConnectors.newClusterConnector("10.20.144.51:2181", "example", "", "");

鏈接成功後，canal server會記錄當前正在工作的canal client信息，比如客戶端ip，鏈接的端口信息等 (聰明的你，應該也可以發現，canal client也可以支持HA功能)

1 [zk: localhost:2181(CONNECTED) 17] get /otter/canal/destinations/example/1001/running
2 {"active":true,"address":"10.12.48.171:50544","clientId":1001}

數據消費成功後，canal server會在zookeeper中記錄下當前最後一次消費成功的binlog位點. (下次你重啟client時，會從這最後一個位點繼續進行消費)

1 [zk: localhost:2181(CONNECTED) 16] get /otter/canal/destinations/example/1001/cursor
2 {"@type":"com.alibaba.otter.canal.protocol.position.LogPosition","identity":{"slaveId":-1,"sourceAddress":{"address":"10.20.144.15","port":3306}},"postion":{"included":false,"journalName":"mysql-bin.002253","position":2574756,"timestamp":1363688722000}}

5、重啟一下canal server

停止正在工作的10.20.144.51的canal server

這時10.20.144.22會立馬啟動example instance，提供新的數據服務

1 [zk: localhost:2181(CONNECTED) 19] get /otter/canal/destinations/example/running
2 {"active":true,"address":"10.20.144.22:11111","cid":1}

與此同時，客戶端也會隨著canal server的切換，通過獲取zookeeper中的最新地址，與新的canal server建立鏈接，繼續消費數據，整個過程自動完成

5.1 觸發HA自動切換場景 (server/client HA模式都有效)

5.1.1 正常場景

① 正常關閉canal server(會釋放instance的所有資源，包括刪除running節點)

② 平滑切換(gracefully)

操作：更新對應instance的running節點內容，將"active"設置為false，對應的running節點收到消息後，會主動釋放running節點，讓出控制權但自己jvm不退出，gracefully.

1 {"active":false,"address":"10.20.144.22:11111","cid":1}

5.1.2 異常場景

① canal server對應的jvm異常crash，running節點的釋放會在對應的zookeeper session失效後，釋放running節點(EPHEMERAL節點)

ps. session過期時間默認為zookeeper配置文件中定義的tickTime的20倍，如果不改動zookeeper配置，那默認就是40秒

② canal server所在的網絡出現閃斷，導致zookeeper認為session失效，釋放了running節點，此時canal server對應的jvm並未退出，(一種假死狀態，非常特殊的情況)

ps. 為了保護假死狀態的canal server，避免因瞬間runing失效導致instance重新分布，所以做了一個策略：canal server在收到running節點釋放後，延遲一段時間搶占running，原本running節點的擁有者可以不需要等待延遲，優先取得running節點，可以保證假死狀態下盡可能不無謂的釋放資源。 目前延遲時間的默認值為5秒，即running節點針對假死狀態的保護期為5秒.

數據同步canal服務端HA配置