故障切换是什么
故障切换把服务从故障侧转移到可用侧，分计划内切换与计划外切换两类。计划内切换发生在维护、升级与演练窗口，可以提前核对与预演；计划外切换由故障触发，时间压力大、信息不全，是真正容易出错的一类。切换的核心不是『能不能切』，而是『切得确定』。
两类切换对照
| 维度 | 计划内切换 | 计划外切换 |
|---|---|---|
| 触发 | 维护、演练、升级 | 故障、断电、网络中断 |
| 准备度 | 可提前核对与预演 | 时间压力大，依赖手册 |
| 风险 | 低，可回退 | 高，决策与隔离容易出错 |
| 重点 | 窗口协调与回切计划 | 快速判定、防脑裂、数据校验 |
基本信息
| 关键动作 | 判定、隔离、提升、引流、验证、通知 |
|---|---|
| 最大风险 | 未隔离故障侧就提升备侧，形成双写 |
| 验证方式 | 切换演练，覆盖计划内与模拟故障两种 |
| 回切要求 | 恢复原主侧后按计划回切，并重新建立复制关系 |
计划外切换步骤
计划外切换步骤
1) 判定：确认是故障而非抖动（多路监控交叉验证）
2) 隔离：切断故障侧写入，避免双写
3) 提升：备侧数据库转主、应用启动
4) 引流：切换 VIP、DNS 或网关
5) 验证：核心链路冒烟测试
6) 通知：同步相关方并记录时间线切换失败的常见原因
- 隔离不彻底：故障侧网络恢复后继续接受写入，两侧数据分叉
- 缺少提升前置检查：复制延迟未归零、只读状态异常时直接提升，丢数据
- 配置漂移：备侧的应用配置、证书、连接池与生产长期不同步，接管时暴露
- 验证不完整：数据库起来了但没有业务冒烟测试，实际服务不可用
- 没有回切计划：故障侧恢复后长期处于不确定状态，复制关系无人重建
切换不是『点一个按钮』：没有隔离动作的自动化切换在脑裂场景下可能扩大事故，无法隔离故障侧时应转为人工决策。
计划内切换是验证计划外切换的最好方式：在可控窗口里把每个步骤走一遍，比在故障当天第一次执行要安全得多。