接地气：错过Percona Live Amsterdam让我对HA有了哪些新的认识
坐在机场的地板上，眼睁睁地看着出发航班信息牌因为关键系统故障而变成一片红色的取消航班，而你这周的日程安排却是全力以赴地维护数据库的高可用性，这真是莫大的讽刺。
与其在 Percona Live 大会上一边吃着焦糖华夫饼一边讨论同步复制与异步复制、灾难恢复策略和连接路由等问题，我不如花几个小时观看英国空中交通管制基础设施实时演示系统故障时会发生什么。
当中央飞行处理系统发生故障时，飞机不会坠毁……人工操作员会手动降低处理能力以确保安全。这对于航空电子设备来说是良好的工程设计。但从操作和用户角度来看，吞吐量会立即降至零。
在数据基础设施领域，我们没有条件对交易进行接地处理。
单点故障剖析
一个系统可以拥有分布在三个可用区的冗余硬件、双电源以及昂贵的供应商合同。然而，如果所有流量都通过单个状态协调器、集中式配置摄取管道或共享控制平面，那么你拥有的就不是分布式系统，而是一个代价高昂的分布式单点故障（SPOF）。
当飞行处理流程因输入格式错误或集中式状态偏差而阻塞时，主节点和辅助节点通常会同时触发安全模式锁定。在我们的系统中，这相当于：
- 裂脑情景当两个主数据库节点锁定表或退出仲裁以防止数据损坏时，就会发生这种情况。
- 健康检查协调器将网络延迟误判为完全故障，导致主连接频繁切换，直到连接池耗尽。
- 一个备份集群，能够在几毫秒内忠实地复制损坏的元数据或毒丸交易。
冗余仅仅是指拥有两份相同的东西。而弹性则是指知道备用件不会重蹈覆辙。
真正的HA需要什么
如果你的系统在凌晨 2 点主路径突然中断后，无法在无人干预的情况下继续运行，那么你并没有实现高可用性，而只是拥有了一个连接在焦虑的工程师身上的警报系统。
- 基于法定人数的共识制应对脆弱的初选：依赖简单主动/被动复制和手动 DNS 故障转移的系统极易导致停机。现代集群（无论是使用 Galera、组复制还是 Raft/Paxos 等共识协议）都需要奇数个节点和法定人数，以确保自动、安全地选举领导者，避免脑裂。
- 智能交通脱钩：应用程序绝不应直接指向数据库节点的硬编码 IP 地址。七层代理、智能连接池（例如 ProxySQL）和虚拟 IP 将应用程序客户端与底层基础设施的频繁变更隔离开来。如果节点 A 发生故障，节点 B 会接管写入操作，应用程序只需不到一秒即可完成重新连接，而不会完全中断。
- 隔离故障域：真正的高可用性 (HA) 会隔离输入。如果包含致命查询或格式错误的配置数据包进入系统，则必须将其隔离。如果主节点在执行过程中崩溃，故障转移不应自动将完全相同的致命查询重放到备用节点上，从而导致整个集群宕机。
- 重在钻探而非文档：如果你还没有在模拟网络分区和高负载条件下测试过自动故障转移，那么你的故障转移计划就只是一个假设。
总结
错过阿姆斯特丹的走廊巡演和现场演示令人遗憾。但凝视着停滞不前的机场航站楼，却让我更加深刻地意识到：停机时间绝不仅仅是 Grafana 仪表盘上的一个抽象指标。它会导致真实的人员滞留、运营中断，并摧毁信任。
做好容错设计。实现故障恢复自动化。测试集群。
作者Aaron West，SIOS 销售工程师
经许可转载SIOS
