第 3 篇：高可用、备份与容灾的真实成本
云数据库产品页特别喜欢把高可用、自动备份、跨区容灾这些词放在一起，给人的感觉像是：你把几个开关一勾，数据库就稳了。这种理解在采购阶段很省事，在生产环境里很危险。
因为高可用、备份、容灾，听起来像一套能力，实际上解决的是三类完全不同的问题。
高可用解决的是实例故障
高可用要解决的，主要是实例级故障。比如节点挂了、宿主机故障、磁盘坏了、某个可用区里的实例失效。这时候你的目标不是“什么都没发生”，而是“尽快恢复成一个还能提供服务的主实例”。
典型手段包括主备架构、多可用区部署、自动故障切换。它的价值很明确，就是把单点故障变成短时抖动。
但高可用不保证下面这些事：
- 业务请求在切换期间完全无感
- 长事务、连接池、重试逻辑不会出问题
- 误删数据可以恢复
- 区域级故障一定能被覆盖
这里一定要把边界认清。数据库自动切换成功，不等于业务已经恢复。因为业务层还要面对：
- 连接被踢掉后能不能自动重连
- 中间件缓存的连接信息会不会过期
- 事务执行到一半被切断后如何处理
- 读写分离组件会不会路由错
- 应用的超时和重试会不会把瞬时抖动放大成雪崩
所以高可用本质上是在缩短实例故障的影响时间，不是在承诺业务绝对无感。
备份解决的是数据可恢复
备份解决的是另一类问题：数据出错了，能不能找回来。
常见场景包括：
- 误删表
- 程序 Bug 把数据批量写坏
- 运维误操作执行了错误更新
- 某个版本上线后把业务数据污染了
这时候高可用一点用都没有，因为主备会把错误一起复制过去。能救你的，只有备份和时间点恢复。
但很多团队对备份的理解还停在“平台每天自动快照”。这远远不够。你至少要把这些问题答清楚：
- 备份频率是多少
- 最长保留多久
- 是否支持时间点恢复
- 恢复一套实例需要多久
- 恢复出来的数据如何校验
尤其最后两个问题特别关键。因为真实事故里，你不是只要“有备份”，你要的是“在业务能接受的时间里，恢复出一套可信的数据”。
没有演练过的备份，严格来说不叫恢复能力，只能叫心理安慰。
容灾解决的是更大范围的失效
容灾要应对的，是比实例故障更大一级的问题。比如可用区级中断、区域网络异常、控制面故障，甚至是整片地域不可用。
一旦进入容灾讨论，两个指标必须出现：RPO 和 RTO。
- RPO 是最多能接受丢失多少数据。
- RTO 是最多能接受业务中断多久。
如果业务要求接近 0 的 RPO 和非常短的 RTO，那方案就会迅速变贵、变复杂。因为你很可能需要：
- 跨可用区甚至跨地域复制
- 更严格的同步或半同步策略
- 独立的流量切换路径
- DNS、网关、配置中心同步切换
- 应用层具备多活或快速重连能力
- 更完整的演练和回切流程
这些能力没有一项是免费的。它们要么牺牲延迟，要么牺牲复杂度，要么直接牺牲预算。
云上最常见的三个误区
误区一：有主备就等于容灾
主备一般覆盖的是实例级、部分可用区级风险，远远不到“区域级容灾”。更重要的是，数据库有主备，不代表你的缓存、消息队列、注册中心、配置中心、入口流量也跟着具备同等级能力。
误区二：自动备份就一定能恢复
如果恢复很慢、恢复流程没人走过、恢复后的数据不会校验，那备份在事故里很可能是摆设。真正的恢复能力至少包含：恢复动作、验证动作、上线动作。
误区三：跨区复制开了就高枕无忧
跨区复制带来的是更高的链路复杂度、网络成本和一致性挑战。没有清晰的切换判定、切换责任人和回切策略，系统不会更安全，只会更复杂。
怎样设计更现实的方案
对大多数业务来说，更现实的做法不是给所有数据库都上最高规格容灾，而是按业务重要性分层。
第一层，实例高可用。先解决单点故障和常见节点故障。
第二层，备份可恢复。确保误删、误更新、逻辑污染之后能按预期回到某个时间点。
第三层，关键业务容灾。只给真正关键的系统上跨可用区、跨地域甚至双活能力，而不是对所有系统一刀切。
比如内部报表库、离线分析库和支付主库，对 RPO/RTO 的要求显然就不该一样。把所有系统都按支付系统来建设，预算扛不住；都按报表系统来建设，事故扛不住。
你真正需要演练的不是功能，而是流程
很多团队在采购阶段喜欢问“支不支持自动切换”“支不支持时间点恢复”。这些问题当然要问，但它们只说明产品有功能，不说明你的组织有能力用它。
真正决定可靠性的，是流程有没有演练过。至少要演练下面这些动作：
- 主实例故障切换后，应用恢复是否自动完成
- 从备份恢复新实例需要多久
- 恢复后的数据如何与业务侧对账
- 跨区切换后，依赖服务是否同步切换
- 回切时如何避免双写和脏数据
数据库稳定性里最容易被忽略的一句话是：可靠性不是配置项，是反复证明过的流程。
小结
高可用、备份、容灾相关，但不能混着讲。
- 高可用解决实例故障。
- 备份解决数据可恢复。
- 容灾解决更大范围的系统失效。
云数据库确实把很多能力做成了现成服务，但这些服务是否能在事故里真正救你，取决于目标定义是否清楚、业务边界是否明确、演练是否到位。
下一篇我们聊一个同样容易被简单化处理的问题：性能治理。