数据库高可用架构设计与故障切换机制 题目描述 高可用性（High Availability, HA）是数据库系统设计的核心目标之一，指系统在出现局部故障时仍能持续提供服务的能力。面试中常要求设计高可用架构，并解释故障检测、切换流程及数据一致性保障机制。 1. 高可用架构的核心组件 （1）冗余部署 主从复制 ：主节点（Primary）处理写操作，从节点（Replica）同步数据，提供读服务。 多节点部署 ：至少部署一主多从（如一主两从），避免单点故障。 （2）故障检测机制 心跳检测 ：主节点定期向从节点或监控节点发送心跳包（如每秒一次）。 超时判定 ：若连续超时（如3次未响应），判定主节点故障。 （3）自动故障切换（Failover） 切换控制器（如Keepalived、Patroni）自动提升新主节点，通知客户端连接新主。 2. 高可用架构的典型方案 方案一：主从+VIP漂移 步骤 ： 主节点绑定虚拟IP（VIP），客户端通过VIP访问。 故障时，控制器将VIP漂移到健康从节点，并重置复制关系。 缺点 ：VIP切换可能因DNS缓存或客户端重连延迟导致短暂不可用。 方案二：基于共识算法（如Paxos/Raft） 示例：MySQL Group Replication、ETCD 节点组成集群，写操作需多数节点确认。 主节点故障时，剩余节点投票选举新主，数据一致性由算法保证。 优势 ：强一致性，避免脑裂（Split-Brain）。 3. 故障切换的详细流程 以主从复制+监控节点为例： 故障检测 ： 监控节点每秒检查主节点存活状态。 连续3次超时后，触发切换流程。 数据一致性校验 ： 比较从节点的复制延迟（如通过 SHOW SLAVE STATUS 查看 Seconds_Behind_Master ）。 选择延迟最小的从节点作为新主。 切换操作 ： 旧主隔离 ：强制关闭旧主节点或撤销写权限，防止数据冲突。 提升新主 ：执行 STOP SLAVE; RESET SLAVE ALL; 解除复制关系，启用写权限。 更新路由 ：将客户端连接指向新主（如修改负载均衡配置）。 恢复与同步 ： 旧主恢复后，作为从节点重新加入集群，同步新主数据。 4. 关键问题与解决方案 （1）脑裂问题 成因 ：网络分区导致两个节点同时认为自己是主节点，并行写入造成数据冲突。 解决 ： 仲裁机制 ：引入第三方仲裁节点（如Zookeeper），只有获得仲裁许可的节点才能成为主。 fencing（隔离） ：强制关闭旧主节点的电源或网络访问。 （2）数据丢失风险 场景 ：主节点异步复制时，若主节点宕机且未同步的数据在缓冲区中，可能丢失。 解决 ： 半同步复制 ：要求至少一个从节点确认后才返回写成功（如MySQL半同步复制）。 延迟复制 ：设置从节点延迟同步（如1小时），故障时从延迟副本找回数据。 5. 实战案例：MySQL高可用架构 架构：MHA（Master High Availability） 组件 ： MHA Manager：监控节点，管理切换流程。 MHA Node：部署在每个MySQL节点上的代理。 切换流程 ： MHA Manager检测主节点故障，选择最新数据的从节点。 通过二进制日志（binlog）补全未同步的数据，提升新主。 自动修改VIP配置或通知应用层更新连接。 总结 高可用架构需平衡 一致性 、 可用性 和 容错性 ： 弱一致性场景 ：可采用主从异步复制+VIP漂移，切换快但可能丢数据。 强一致性场景 ：推荐基于Raft的集群方案，保证数据安全但复杂度更高。 故障切换的核心在于 快速检测 、 最小化数据丢失 和 避免脑裂 ，需根据业务需求权衡设计。