前言

在分布式系统中，当主节点因故障被替换（Failover）后，如果原主节点恢复正常，系统是否、何时、以及如何让它重新承担主角色？这便是 Failback（故障恢复切回） 的核心问题。

Failover 解决的是“谁来接管”；Failback 关注的是“如何恢复原本秩序”。

定义

Wiki（简化意译）定义如下：

Failback is the process of restoring operations from a failover system back to the original primary system once it is restored and deemed stable.

一句话：Failback 是故障恢复后，让原主节点重新接手服务的过程。

工作原理

一句话：系统在主节点故障后触发 Failover，待其恢复稳定后，通过 Failback 将其重新设为主节点。

一个典型的 Failback 流程：

  1. 主节点 A 故障 → 备用节点 B 触发 Failover 成为主；
  2. 原主节点 A 恢复 → 系统评估其状态；
  3. 若配置允许，自动或手动将主权从 B 切回 A；
  4. B 转为备用节点，继续同步。

Failback 通常依赖以下机制：

  • 健康检查机制（如 Heartbeat）
  • 数据同步机制（如 Catch-up）
  • 状态转移控制（是否自动）
  • Fencing 机制（防止旧主未隔离就恢复）

属性与指标

Failback 涉及的关键属性有：

  1. 是否启用（Enable/Disable） 是否允许自动 Failback，部分系统默认关闭以避免震荡。

  2. 切回策略（Policy） 自动或手动、是否设置优先级主（prefer-master）、何时触发。

  3. 稳定性判断标准 系统如何判断原主节点已完全恢复，通常包括连续健康心跳、数据追平等。

  4. 数据一致性保障 原主需同步到最新数据，避免数据回滚或丢失。

  5. 抖动控制 防止频繁在主从之间来回切换，可设置冷却时间或抑制周期。

类型

按触发方式分类

  1. 自动 Failback 节点恢复后系统自动完成主权切回，适用于 prefer-master 场景（如 Redis Sentinel）。

  2. 手动 Failback 节点恢复后需人工介入确认、执行恢复切回，适用于强一致性、高安全性场景（如数据库系统）。

按执行方式分类

  1. 在线切换 主从平滑转换，业务不中断，常用于有状态系统。

  2. 重启切换 节点重启触发状态变更，存在一定的服务波动风险。

Failback 与程序关系

Failback 的实际应用广泛：

  1. 数据库主备恢复 比如 PostgreSQL、MySQL MGR、MongoDB 在主库恢复后是否重新切主。

  2. 缓存系统 Redis Sentinel 会尝试将 prefered master 恢复为主节点。

  3. 服务发现系统 etcd、Consul 等在集群恢复后可能重建 leader，进行 Failback。

  4. 负载均衡层 反向代理是否将流量切回原主实例，需结合健康检查策略。

设计时应注意：

  • 原主恢复是否完整，包括配置、数据、网络状态；
  • Failback 是否会引发服务中断或瞬间拥堵；
  • 是否存在 Split-Brain 风险，应结合 fencing；
  • 是否需要通过日志、审计记录追踪 Failback 行为。

常见支持 Failback 的系统

系统/组件 是否支持自动 Failback 控制策略
Redis Sentinel 支持 prefer-master + down-after-milliseconds
MongoDB 支持 自动选主，根据优先级
MySQL MGR 支持 依赖 Group Communication
Pacemaker + Corosync 支持 自定义资源策略与健康检查
Kubernetes 支持 Pod 恢复调度