数据库可靠性设计：备份、恢复、容灾与演练
数据库可靠性不只是主从复制，还包括备份可用性、恢复速度、容灾切换、误删回滚和定期演练。
数据库可靠性设计：备份、恢复、容灾与演练
很多系统平时看起来很稳定，直到第一次误删数据、磁盘损坏、主库宕机，才发现备份不可用、恢复太慢、切换流程没人熟。
数据库可靠性设计要回答两个问题：数据最多能丢多少，服务最多能停多久。
RPO 和 RTO
RPO 是 Recovery Point Objective，表示最多能接受丢失多少数据。
RTO 是 Recovery Time Objective，表示最多能接受服务中断多久。
如果业务要求 RPO 接近 0，就需要同步复制、强一致写入或更严格的日志保护。如果业务要求 RTO 很短，就要有自动故障切换和预热好的备库。
主从复制不是备份
复制解决的是高可用和读扩展，不是完整备份。
如果有人在主库误删数据，删除操作也会同步到从库。此时从库并不能天然救你。
备份需要独立保存，并且要能恢复到指定时间点。常见方式包括逻辑备份、物理备份、WAL/binlog 归档和快照。
逻辑备份和物理备份
逻辑备份导出 SQL 或逻辑数据，优点是可读、可迁移，缺点是大库恢复慢。
物理备份复制数据文件，恢复速度通常更快，但和数据库版本、存储结构绑定更紧。
实际系统经常组合使用：定期全量物理备份 + 连续日志归档 + 小表逻辑备份。
时间点恢复
时间点恢复用于处理误删、误更新这类问题。
比如 10:05 有人误执行：
DELETE FROM orders;
如果有 10:00 的全量备份和 10:00 之后的 binlog/WAL，就可以恢复到 10:04:59，再把数据补回生产库。
时间点恢复的关键是日志归档完整、备份可用、恢复流程熟练。
容灾架构
同城多可用区可以抵抗单机房故障。异地容灾可以抵抗城市级故障。
但容灾不是越远越好。距离越远，网络延迟越高，同步复制成本越大。很多系统采用本地强一致、异地异步复制。
容灾切换要提前设计：
- 谁触发切换。
- 如何防止双主写入。
- DNS 或路由如何切。
- 应用连接如何刷新。
- 切回流程怎么做。
演练比文档重要
没有演练过的恢复方案，不能算真正存在。
演练要覆盖：
- 从备份恢复新实例。
- 恢复到指定时间点。
- 主库故障切换。
- 误删数据回补。
- 备份文件损坏场景。
每次演练都要记录耗时，检查是否满足 RTO 和 RPO。
小结
数据库可靠性不是一句“有主从”就够了。真正可靠的设计包括：
- 明确 RPO/RTO。
- 定期备份。
- 日志归档。
- 恢复验证。
- 容灾切换。
- 误删回滚。
- 定期演练。
备份没有恢复过，就不能证明它有用。