故障转移

主节点故障后由副本接管写入的过程;涉及故障检测、选主、切换与客户端重连,切换期间常伴随短暂不可写与数据回退风险,需要演练验证。

故障转移是什么

故障转移是主节点故障后由副本接管写入的过程,包含故障检测、选主、提升新主、客户端重连与旧主回归几个环节。切换期间通常有短暂不可写窗口,异步复制下还可能丢失最近的写入,因此切换策略必须与数据容忍度一起设计。

为什么必须演练

切换脚本里的权限配置、网络策略、客户端地址缓存,任何一项缺失都会让真实故障时的自动切换失败。演练的价值在于暴露出这些平时看不见的依赖,而不是验证脚本本身能跑通。没有演练过的切换流程,实质上等于没有切换流程。

典型流程

典型流程
1. 故障检测(心跳超时或健康检查连续失败)
2. 选主(共识协议或仲裁,确保唯一)
3. 提升新主,旧主降级为副本
4. 客户端刷新路由并重连          # 注意连接池与本地地址缓存
5. 旧主回归后按规则回补数据并校验,确认无分叉

切换与回归检查

阶段检查项
切换前复制延迟在阈值内;脚本与权限就绪
切换中选主唯一;旧主已被隔离或降级
切换后客户端路由刷新;写入恢复;监控正常
回归旧主数据回补与校验,确认无数据分叉

基本信息

检测心跳超时或健康检查失败,阈值需按网络抖动实测
选主共识协议或仲裁,核心是避免双主
客户端路由刷新与重连,注意连接池与本地地址缓存
回归旧主回补数据并校验,防止两份数据分叉

自动还是手动

自动切换能把停机时间压到最短,但误判代价高,网络抖动或短暂停顿都可能触发一次不必要的切换;手动切换更可控,却依赖人是否在线以及判断是否及时。常见折中是分级处理:单节点故障自动切换,涉及跨机房或数据回退风险的场景要求人工确认。无论哪种方式,切换前的数据状态判定都要有明确标准。

检测超时过短会造成误切换,过长则停写时间拉长;阈值要结合业务容忍度与网络抖动实测确定,不能照搬默认值。

易错点

  • 未演练切主流程,真实故障时切换脚本因权限或网络策略执行失败
  • 切换后客户端仍缓存旧主地址,写入持续失败直到应用重启
  • 旧主恢复后直接重新加入写服务,未隔离导致双主写入
  • 切换脚本依赖故障地域内的控制组件,灾难发生时自身不可用

数据来源与参考

  • 《数据密集型应用系统设计》(Kleppmann)第 5、9 章
  • AWS Well-Architected Framework:Reliability Pillar
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌