3. 主从切换架构概述
主从复制与切换是保障数据库、缓存及中间件高可用性的核心手段。本章从基本原理出发，梳理触发条件与切换模式，为后续 Error Budget 变更窗口下的部署实战奠定架构基础。
3.1 主从架构的基本原理
主从架构通过将数据写入集中到单一主节点，再异步或半同步复制到多个从节点，实现读写分离与故障转移。其核心组件与数据流如下：
核心组件：
- 主节点（Primary/Master）：接受写请求，记录变更日志（Binlog / WAL / Oplog）。
- 从节点（Replica/Slave）：拉取主节点日志，重放变更，保持数据最终一致。
- 复制通道（Replication Channel）：基于 TCP 的长连接，传输日志或行级变更。
- 心跳/探活（Heartbeat）：主从之间定期交换状态，检测节点存活。
3.2 主从切换的触发条件
触发主从切换的条件可分为故障类与计划类两大类。在 Error Budget 变更窗口场景中，计划类切换是主要关注点。
| 触发类型 | 具体条件 | 典型场景 | 对 Error Budget 的影响 |
|---|---|---|---|
| 故障类 | 主节点宕机、网络分区、磁盘满、内核 panic | 硬件故障、云实例意外终止 | 消耗 Error Budget（不可用时间计入 SLO） |
| 计划类 | 内核升级、硬件替换、配置变更、版本升级 | 变更窗口内的主从轮换 | 可提前规划，尽量不消耗 Error Budget |
| 退化类 | 复制延迟超过阈值、主节点性能严重劣化 | 慢查询导致复制堆积、IO 打满 | 视切换耗时决定是否计入不可用 |
关键原则：计划类切换应通过优雅排空连接、预加热从节点、灰度流量验证等手段，将切换对用户的影响降至最低，从而避免消耗 Error Budget。
3.3 主从切换的常见模式
根据切换决策主体和执行方式，主从切换分为手动切换与自动切换两种模式。现代生产环境通常采用“自动检测 + 人工确认”的混合策略。
3.3.1 手动切换
- 执行方式：运维人员通过 CLI 或管理平台执行
switchover命令。 - 适用场景：计划内变更、灰度验证、故障演练。
- 优点：可控性强，可提前检查复制状态、延迟、连接数。
- 缺点：依赖人工响应，MTTR 较长（通常 5~15 分钟）。
3.3.2 自动切换
- 执行方式：由集群管理组件（如 Orchestrator、Patroni、MHA、Sentinel）自动探测故障并触发切换。
- 适用场景：突发故障、非工作时间、大规模集群。
- 优点：MTTR 短（通常 30~120 秒），减少人为失误。
- 缺点：可能引发脑裂、误切换；需要完善的 fencing 机制。
3.4 切换模式选型建议
| 评估维度 | 手动切换 | 自动切换 | 混合策略 |
|---|---|---|---|
| MTTR | 5~15 分钟 | 30~120 秒 | 1~5 分钟 |
| 脑裂风险 | 低（人工确认） | 中（需 fencing） | 低（人工确认 fencing） |
| 变更窗口适配 | 适合计划内变更 | 适合故障自愈 | 适合 Error Budget 敏感场景 |
| 运维成本 | 高（需 7×24 值班） | 低（自动化） | 中（需搭建审批流） |
实践建议：在 Error Budget 变更窗口项目中，推荐采用“自动探测 + 人工确认”的混合策略。日常变更使用手动切换以精确控制窗口消耗；突发故障时自动切换兜底，但通过 Webhook 通知值班人员确认，避免误切换导致 Error Budget 意外消耗。