适用场景
数据库高可用的目标是"故障时业务能继续"，而不是"永远不宕机"。关键是切换要快、数据要一致、切换后要有人知道。
配置步骤（故障切换（自动 + 人工））
# 1) 切换前：确认从库延迟、应用连接池指向
# 2) 执行切换：提升从库为主库，重置复制指向
# 3) 应用侧：更新连接地址（VIP/DNS 或代理层）
# 4) 校验：数据一致性 + 业务读写验证
# 5) 记录：切换时间、丢失数据、根因关键参数与建议
- 复制模式选择：同步/半同步（强一致，性能略降）vs 异步（性能好，可能丢数据）
- 切换要自动化但可人工干预，切换后必须校验数据完整性
- 读写分离要把"强一致性读"走主库（如支付后立即查询）
- 延迟监控与告警必须有，延迟大时自动摘除从库
- 定期做切换演练与备份恢复演练，两件事不能省
容易踩的坑
- 切换后应用仍连旧主库（连接池缓存），业务异常
- 未校验一致性，出现部分数据缺失
- 切换过程无记录，事后无法复盘
验证与巡检
# 验证：写一条数据并在新主库读到；检查应用连接数- 巡检：切换演练报告、连接配置更新记录
小结
数据库高可用的验收标准：模拟主库故障，业务在约定时间内恢复，且数据一致性校验通过。做不到就还在"纸面高可用"。
> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。