数据库出现故障时，能否恢复服务和能否找回数据是两件事。规划云端数据库高可用方案，应分别安排故障切换、备份恢复与定期演练，再依据业务可接受的中断时间和数据损失量选择架构。仅有副本不等于有备份：误删或错误写入也可能同步到副本。
先把恢复目标说清楚
RPO 表示可接受的数据丢失范围，RTO 表示恢复服务所需时间。两者应由业务负责人和技术团队共同确认，而不是直接照搬产品默认值。若允许丢失数分钟数据，可评估异步复制和较频繁的日志备份；若希望尽量缩短数据损失窗口，则要考察同步复制的延迟、网络条件及写入性能影响。
RTO 也不只取决于数据库重新启动的速度。应用连接重试、名称解析缓存、权限检查和恢复后的数据校验都占用时间。把恢复目标写成可验收的指标，例如“在约定的演练环境中，恢复关键读写功能”，比笼统要求“快速恢复”更有用。
按运维能力选择架构
托管数据库：减少基础设施维护
Amazon RDS Multi-AZ 可用于需要托管式故障切换的场景；具体数据库引擎和配置会影响可用能力、切换过程及只读副本选项。选择前要核实故障检测、切换触发条件、连接端点行为和备份保留设置。优点是减少主机、复制进程等日常维护，限制则是故障处置方式和底层细节受服务配置约束。
自建复制：控制更细，责任也更多
PostgreSQL 可用流复制建立备用节点，并通过 Patroni 等工具协调集群管理；MySQL 可评估 InnoDB Cluster。自建方式适合有数据库运维能力、需要定制复制或故障处理策略的团队，但必须自行维护仲裁、监控、升级和演练流程。无论采用哪种方式，都要防范双主写入或旧主节点恢复后继续接收写入造成的数据分歧。
把故障切换与备份恢复连起来
故障切换关注服务连续性，备份恢复关注误操作、逻辑损坏或更大范围故障后的数据回退。数据库副本可能复制误删，备份应与运行中的数据库故障域适当隔离，并限制访问权限。以 PostgreSQL 为例，可结合基础备份与 WAL 归档实现时间点恢复；具体恢复能力取决于归档完整性、保留周期和恢复配置。
- 盘点依赖：记录数据库引擎、版本、容量、写入特点、应用连接方式，以及账号和加密密钥等恢复所需信息。
- 设定目标：为不同数据和服务确定 RPO、RTO，并确认复制模式、备份频率与保留期限能否支持目标。
- 配置保护：启用产品支持的自动备份或自建备份流程；对需要时间点恢复的数据库，检查事务日志是否持续归档，并将备份保存到独立位置。
- 验证可用性：按计划在隔离环境恢复备份，检查表、账号、权限及关键查询；记录从开始恢复到应用可正常读写的时间。
- 演练切换：在维护窗口或测试环境模拟主节点不可用，确认告警、切换结果、客户端重连及恢复后的数据一致性，并补充回切步骤。
容易遗漏的检查项
监控不能只看主机是否在线。应关注复制延迟、备份任务结果、日志归档中断、存储空间和连接错误；告警需发送给明确的值班责任人。还应检查备份账号是否有过宽权限，并确保密钥、网络策略和操作手册在故障时可用。高可用架构若没有恢复测试，实际恢复能力仍未得到验证。
因此，云端数据库高可用方案应以可验证的故障切换和备份恢复为核心：先定 RPO、RTO，再选托管或自建架构，最后用演练证明目标能够实现，并在版本、容量或业务要求变化后重新评估。
常见问题
有只读副本，还需要备份吗？
需要。副本可帮助分担读取或接替节点，但误删、逻辑错误可能被复制；独立备份用于回到较早时间点。
同步复制一定比异步复制好吗？
不一定。同步复制通常更强调数据确认，但可能增加写入延迟，并受网络与节点状态影响；异步复制响应较快，但故障时可能丢失尚未复制的数据。
多久做一次恢复演练？
应按业务风险、系统变更频率和合规要求确定。至少在架构调整、数据库升级或恢复配置变更后重新验证，并定期进行例行演练。
备份成功提示是否代表能恢复？
不代表。还需实际恢复到隔离环境，检查数据完整性、权限、应用连接及恢复耗时。