Canal 高可用（HA）与故障转移（Failover）机制深度剖析：从 ZooKeeper 选举到无缝数据接力
问题原文：“在集群模式下，Canal 是如何实现高可用（HA）和故障转移（Failover）的？”
本文将面向一位具备 Flink、Kafka、Hudi 等大数据生态深厚功底的工程师，系统性地拆解 Alibaba Canal 1.1.8 在集群模式下的 高可用（HA） 与 故障转移（Failover） 核心机制。我们将通过一个典型的 跨云 MySQL 数据灾备 场景——要求在单个可用区（AZ）完全失效的情况下，数据同步链路能在秒级内自动恢复，深入剖析 Canal 如何利用 ZooKeeper 的分布式锁、临时节点和 Watch 机制，实现无损、无缝的故障切换，并揭示其背后的状态机设计、位点管理策略与生产调优要点。
一、业务痛点引入：AZ 故障导致的同步中断
某全球化电商平台采用“同城双 AZ”架构。核心商品库 product_catalog 部署在 AZ-A 的 MySQL 主库上。为了灾备，需要将其变更实时同步至 AZ-B 的备用集群。
初期，团队在 AZ-A 部署了单台 Canal Server。当一次大规模的网络故障导致整个 AZ-A 不可用时，Canal Server 随之宕机，同步链路中断。由于缺乏自动故障转移能
