设计云数据库时，先分清两个问题：数据如何到达备用节点，故障后又由谁决定切换。云主机数据库主从部署与自动故障切换设计，需要同时考虑这两条路径，而不是只把一台主库和一台从库连起来。以 PostgreSQL 或 MySQL 为例，复制能缩短备用节点追赶数据的时间，却不会自动保证应用连到正确节点，也不能替代备份。
复制解决数据副本，切换解决服务连续性
主从复制通常把主库的变更传到一个或多个副本。异步复制对主库写入的等待影响较小，但主库突然损坏时，尚未送达副本的事务可能丢失；半同步复制会等待至少一个副本确认收到或写入日志，具体确认条件依数据库配置而异，通常能降低数据缺口，但会增加写入延迟，并不等同于零数据丢失。
自动故障切换还要完成故障判定、候选节点选择、提升副本、阻止旧主库继续写入，以及更新应用连接目标。若只配置复制而没有这些控制环节，运维人员仍需人工判断和操作。设计时应明确 RPO（可接受的数据丢失量）和 RTO（可接受的恢复时间），并把它们作为测试目标，而非未经验证的保证。
先选部署路径，再确定切换责任
| 方案 | 适用条件 | 主要取舍 |
|---|---|---|
| 云厂商托管数据库 | 希望减少主机维护，且所需数据库版本、网络和切换能力均受支持 | 日常运维负担较轻；故障检测、切换时长和可调参数受具体产品约束 |
| 云主机自建数据库 | 需要控制操作系统、数据库参数或拓扑，团队能承担值守 | 配置灵活；补丁、安全、备份、监控、仲裁和演练都由团队负责 |
自建 PostgreSQL 高可用时，可评估 Patroni，并为其配置受支持的分布式配置存储，例如 etcd；MySQL 则可依据版本与运维能力选择 GTID 复制和相应的故障管理工具。工具负责协调，不会消除网络分区、权限错误或配置不一致的风险。云主机数据库主从部署与自动故障切换设计应先确定责任边界：谁发现故障、谁批准或执行提升、谁维护应用连接配置。
把恢复路径拆成可检查的步骤
- 定义故障边界：区分单个数据库进程故障、主机故障、可用区网络中断和整区故障；按风险决定副本是否放在不同主机或不同可用区。跨区通常能改善隔离能力，但会增加网络时延，并可能产生额外费用，实际影响取决于云服务和区域。
- 确认副本可接管：监控复制延迟、日志位置、磁盘空间和副本健康状态。不要只看“连接正常”；延迟过大时，自动提升可能扩大数据缺口。
- 设置防止双主的措施：控制旧主库写入权限，或使用隔离机制 fencing，使失去控制面的旧节点不能继续接收写入。否则网络分区期间新旧节点都可写，会造成冲突和后续数据整理。
- 规划应用入口：使用托管服务提供的连接地址，或由受控代理、服务发现更新目标。设置合理的连接超时与重试，避免客户端长期持有失效连接；重试写操作前还要考虑幂等性，防止事务已提交但响应丢失时重复执行。
- 演练并记录回切：在非生产环境验证主库不可用时的提升、应用重连和数据核对；再演练旧主库恢复后如何重建为副本。不要直接把旧主库重新开放写入。记录各阶段耗时、数据差异和人工步骤，按结果调整目标。
复制不能替代备份，自动切换也不是无损承诺
删除、错误更新或勒索软件造成的数据变化，可能同样复制到从库；因此仍需独立备份，并验证可恢复性。备份应考虑保留周期、访问权限和恢复所需时间，恢复测试要覆盖数据库文件或快照之外的配置、密钥与连接信息。若业务要求低数据丢失，应结合复制确认策略、备份和恢复流程评估，而不是只依赖“自动”二字。
最终，云主机数据库主从部署与自动故障切换设计的重点，是让副本、判障、隔离、连接切换和回切形成闭环。选择托管服务还是自建，取决于团队是否愿意接手故障协调与持续演练；任何方案都应以实际测试结果界定恢复能力。
常见问题
主从复制开启后，故障会自动恢复吗？
不一定。复制只传递数据，还需配置故障检测、节点提升、旧主隔离和应用连接更新；托管服务是否自动处理这些环节，应核对具体产品能力。
异步复制一定会丢数据吗？
不一定，但主库故障时可能有尚未复制的事务。风险大小受写入速度、网络状态和副本延迟影响，应监控延迟并结合 RPO 选择策略。
有从库还需要备份吗？
需要。从库可能同步删除或错误写入，不能单独承担历史恢复。应保留独立备份并定期验证恢复流程。
切换后可以马上把旧主库切回来吗？
通常不应直接回切。先确认旧主库已隔离写入，再依据当前主库重建或追平数据，完成一致性检查后，按预案安排回切。