Cloud SQL只读副本（read replica）是否可用于高可用（HA）场景？

你对两段文档的描述不存在理解偏差，两者针对的是完全不同的故障场景，核心要区分「整体数据库架构的可用性」和「只读副本自身的高可用能力」两个独立概念：

第一段文档的适用场景 #

对应的是主实例所在可用区发生故障的情况：

• 只读副本部署在异可用区的核心价值是避免和主实例同时故障，主实例所在可用区宕机时，异可用区的副本仍然可以正常承接读流量
• 此时你可以手动将该只读副本提升为新的主实例，承接写流量，相当于为灾备场景提供了可选的恢复路径，这是它可以辅助提升架构可用性的原因

第二段文档的适用场景 #

对应的是只读副本自身所在可用区发生故障的情况：

• 开启HA的主实例本身采用跨可用区双活部署，单可用区故障时会自动完成主备切换，业务中断时间极短
• 普通只读副本为单可用区部署，没有配套的备用实例，一旦它所在的可用区发生故障，这个副本会直接不可用，平台不会自动为它做故障转移，指向它的读流量就会中断，这就是只读副本自身不具备HA能力的核心原因

能力边界总结 #

只读副本的核心定位是分流读请求、支撑跨区域数据同步，它本身不是高可用解决方案：

• 它可以在主实例故障场景下提供额外的恢复选项，辅助提升整体架构的可用性
• 但它自身没有自动故障转移能力，不能替代主实例的HA配置，也无法保障单副本自身的服务连续性
• 如果要实现读链路的高可用，可以在多个不同可用区部署多份只读副本，通过业务层负载均衡或者数据库代理层实现故障时的流量自动切换

内容的提问来源于stack exchange，提问作者aName