高可用解决“服务尽快继续”，备份解决“找回独立历史副本”，两者不能替代。真正可交付的方案必须写出故障模型、RPO、RTO，并用恢复演练证明。
Table of contents
Open Table of contents
先定义失败会发生在哪里
列出进程崩溃、主机损坏、可用区断网、误删、凭证泄露、静默数据损坏和整库逻辑污染。单机自动重启只能处理其中很小一部分；同机副本也无法抵御磁盘和机房故障。
RPO（恢复点目标）是最多可丢失的数据时间，RTO（恢复时间目标）是最多可中断多久。例如“RPO 5 分钟、RTO 30 分钟”比“必须高可用”可测试得多。
三层保护
- InnoDB 崩溃恢复处理未刷数据页和未完成事务。
- 副本与集群提供冗余、读扩展和故障切换候选。
- 全量/增量备份加 Binlog 提供独立副本和按时间点恢复。
备份应跨故障域保存、加密、限制删除权限并设置不可变保留策略。副本会忠实复制 DROP TABLE，所以它不是防误删备份。
一次恢复演练怎么做
在隔离环境恢复最新全量备份；校验备份清单和校验和；回放 Binlog 到误操作前的精确位置；执行行数、关键聚合、外键/业务不变量检查；让应用做只读验收；记录实际 RPO、RTO 与每个手工步骤。
恢复命令随备份工具、部署方式和安全策略而变化，因此实验室不提供会覆盖数据库的“一键脚本”。可从 MySQL 备份与恢复手册选择逻辑备份、物理备份或 MySQL Shell，再为自己的环境写经过审阅的运行手册。
高可用验收清单
监控复制延迟和仲裁状态；客户端能发现新主；只允许单一写主；切换与回切都有负责人和停止条件；备份恢复演练定期成功；密钥、备份目录和生产账号权限分离。
下一步
继续阅读06-17 分库分表、历史归档与在线迁移，处理单集群容量边界和数据生命周期。