故障转移、演练与恢复验证
故障转移把流量和写入权交给健康副本，演练和恢复验证用于确认切换后业务与数据都处于可接受状态。
1. 先定义触发条件
故障转移需要区分进程故障、节点故障、网络分区、依赖故障和性能退化。单一心跳失败不足以覆盖这些情况，也容易因短暂抖动误切换。
触发判断可以组合：
- 多个位置的主动健康检查；
- 用户请求错误率和延迟；
- 复制状态与数据新鲜度；
- 节点租约或共识状态；
- 运维确认和变更上下文。
检测阈值需要平衡发现速度和误报。连续失败次数、恢复迟滞和最短稳定时间可以防止两个节点之间反复切换。
2. 写入切换需要 fencing
网络分区时，旧主节点可能仍在运行，只是无法与控制面通信。直接让备用节点开始写入，可能形成两个主节点。
fencing 通过租约、任期、仲裁、存储令牌或断电隔离，确保旧主无法继续提交写入。每次领导权变化都带上单调递增的 epoch，下游只接受当前 epoch 的请求，也是一种常见做法。
只有健康检查、没有写入权协议的主备系统，无法可靠处理网络分区。故障转移设计必须说明谁拥有最终裁决权。
3. 数据就绪后再接管
备用节点可连接，不代表适合接管。切换前至少检查：
- 复制延迟是否满足 RPO；
- 日志是否完整、校验是否通过；
- 应用版本和数据库 schema 是否兼容；
- 缓存、索引和本地状态是否预热；
- 剩余容量能否承担目标流量。
同步复制系统还要确认多数派和提交位置；异步复制系统需要明确会丢失或重复哪些写入。恢复后通过业务幂等键、流水和对账修复边界数据。
4. 流量切换按阶段执行
一次可控切换可以分为：
- 冻结高风险变更并建立事件指挥；
- 确认目标节点、数据位置和容量；
- 先切少量探测或内部流量；
- 检查错误、延迟、数据和下游状态；
- 分批扩大流量；
- 宣布新拓扑并更新监控与值班信息。
DNS 切换要考虑 TTL 和客户端缓存，连接型协议还要处理已有长连接。即使控制面显示流量已经迁移，也要从多个用户位置确认真实路径。
5. 恢复验证覆盖业务结果
基础设施健康检查通常只验证端口、进程或简单查询。恢复验证还需要：
- 创建、查询和更新一条测试业务记录；
- 确认消息发布与消费继续推进；
- 比较关键账务、库存或状态机不变量；
- 检查异步积压、定时任务和第三方回调；
- 从用户入口执行端到端合成探针。
验证数据要有独立标识并能安全清理。涉及真实资金或通知时，使用沙箱账户和无副作用路径。
6. 演练从小故障开始
演练应有假设、范围、停止条件和观察指标。可以逐级覆盖：
- 终止单个实例；
- 隔离一个节点或可用区；
- 限制依赖延迟和带宽；
- 暂停复制或使备用节点落后；
- 模拟区域不可用并执行恢复计划。
首次演练先在预生产或小流量环境验证自动化。生产演练控制爆炸半径，准备立即终止和人工接管渠道。演练目的是验证系统假设和团队协作，不追求制造更大的故障。
7. Runbook 必须可以直接执行
有效 runbook 包含前置检查、命令或控制台路径、每一步预期结果、负责人、超时和回退动作。关键凭据和工具不能只存在于故障区域。
演练时让非作者按 runbook 操作，最容易发现隐含知识。每次系统版本、拓扑、证书或组织责任变化后，都要更新并重新验证相关步骤。
自动化脚本同样需要 dry-run、审计、幂等和权限最小化。一个未经演练的自动切换脚本只是另一项风险。
8. Failback 是独立迁移
原主节点恢复后，不应立即抢回流量。需要先确定当前权威数据源，修复旧主状态，重新建立复制并追平，再按普通灰度流程切回。
有时继续使用新主比立即回切更安全。Failback 的时机由风险、性能、运维窗口和长期拓扑决定，不能只因为旧节点“恢复绿色”就执行。
9. 用数据评估演练
每次演练记录：
- 检测时间、决策时间和切换时间；
- 实际 RTO、RPO 和用户影响；
- 人工步骤、权限阻塞和沟通延迟；
- 告警是否准确、文档是否可执行；
- 恢复后数据差异和积压清理时间。
发现项转为有负责人、优先级、期限和验收方式的任务，并安排复测。只保存演练报告，没有关闭行动项，不能提高下一次恢复能力。
10. 面试题
10.1 怎样设计并验证数据库主备故障转移
出现公司：字节跳动
考察重点
- 故障检测、仲裁和 fencing。
- 复制位置、RPO、接管容量与流量切换。
- 业务验证、failback 和演练闭环。
相关内容：第 1 节“先定义触发条件”至第 9 节“用数据评估演练”。
参考回答
我会先定义主机故障、网络分区和性能退化的检测信号，使用多点探测、用户错误和复制状态综合判断，并设置迟滞防止抖动。写入切换必须经过多数仲裁、租约或 epoch fencing，确保旧主不能继续提交。
备用节点接管前检查复制位置、版本、容量和数据完整性，再从探测流量逐步扩大。切换后通过端到端业务探针、关键不变量、消息积压和数据对账验证。原主恢复后先追平和校验，再单独安排 failback。最后定期做受控故障演练，记录实际 RTO/RPO，把文档、权限和自动化缺口转成可验收任务并复测。