这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据库高可用
场景
某天凌晨，数据库主节点宕机。
事件：
- 主数据库服务器硬件故障
- 所有写操作失败
- 从库无法同步
- 系统部分不可用
影响：
- 用户注册失败
- 订阅更新失败
- 日志记录失败
- 持续时间：2 小时（人工处理）解决方案：自动故障转移
选型边界
为什么从人工切换走向 MHA
- 触发问题
- 主库故障后人工处理耗时 2 小时，写操作长时间不可用，恢复过程也依赖人的判断。
- 候选方案
- 人工主从切换、自研故障转移脚本、MHA、托管数据库高可用版。
- 选择理由
- MHA 比自研脚本更成熟，可以处理主库故障检测、候选从库提升和复制关系重建，适合教学阶段理解自动切换链路。
- 代价
- 仍要关注复制延迟、脑裂、防止误切换和切换后的数据校验；自动化不等于零风险。
- 暂不解决
- 暂不讨论强一致多主写入，当前目标是把单主 MySQL 的故障恢复时间从小时级降下来。
1. MySQL 主从切换
设计流程
1. MySQL 主从切换
- 步骤 1：检测故障并完成切换恢复
- 步骤 2：准备数据表、事务边界、归档条件和回滚方案
- 步骤 3：检查健康状态并触发告警
- 步骤 4：检测故障并完成切换恢复
关注点：一致性、查询性能、归档边界和可回滚性。
2. 自动故障转移脚本
设计流程
2. 自动故障转移脚本
- 步骤 1：检查健康状态并触发告警
- 步骤 2：采集健康状态并触发告警
- 步骤 3：确定要处理的数据表、业务记录和一致性边界
- 步骤 4：按一致性要求、数据温度和失败情况选择处理路径
关注点：一致性、查询性能、归档边界和可回滚性。
3. 使用 MHA（MasterHA）
设计流程
3. 使用 MHA（MasterHA）：部署操作
- 步骤 1：准备运行环境并启动服务
- 步骤 2：确定要处理的数据表、业务记录和一致性边界
- 步骤 3：按一致性要求、数据温度和失败情况选择处理路径
- 步骤 4：写入数据变更结果，并保留校验和回滚依据
关注点：一致性、查询性能、归档边界和可回滚性。
监控和告警
设计流程
监控和告警
- 步骤 1：检查健康状态并触发告警
- 步骤 2：采集健康状态并触发告警
- 步骤 3：确定要处理的数据表、业务记录和一致性边界
- 步骤 4：按一致性要求、数据温度和失败情况选择处理路径
关注点：一致性、查询性能、归档边界和可回滚性。
上线前多想一步
- 切换要多快？ 先给自己定一个目标，例如 1 分钟内恢复写入，而不是等故障时再临场判断。
- 会不会丢数据？ 主库挂掉前最后几秒写入的订单、订阅和日志，要有办法查清楚。
- 会不会误切？ 网络抖动不等于主库真的死了，自动切换前要有足够的确认信号。