高可用性
Managed Postgres 提供多种高可用性级别，以满足您的数据持久性和性能需求。您可以在配置数据库时添加一个或两个备用副本，或稍后根据需要在 Settings 页面中调整此配置。
高可用性选项
2 备用节点
采用两个备用节点时，会与主节点一同部署两个副本节点。两台备用节点与主节点规格相同，当主节点发生故障时，任意一台都可以接管。
此配置使用同步复制，即主节点在确认写入之前，会等待至少一台备用节点的确认。这比异步复制提供了更强的数据持久性保证。由于只需要一台备用节点确认（而不是两台都需要），因此相比于仅有单台备用节点的同步复制，其性能影响要小得多。
1 个备用节点
在使用 1 个备用节点的配置下，会在主节点旁边预配一个副本节点。备用节点与主节点规格相同，并可在主节点发生故障时接管。
数据通过异步复制方式复制到备用节点。这意味着写入在主节点上提交时，不会等待备用节点的确认。异步复制确保高可用性不会因额外的网络延迟而拖慢写入速度。然而，这也意味着在主节点发生故障的那一刻，备用节点可能尚未接收到最新的事务。对于大多数应用，这种在性能与最近写入存在小风险丢失之间的权衡是值得的。如果需要确保写入的持久性，建议使用 2 个备用节点。
无 Standby
在该选项下，只会按你所选择的规格预配一个 primary 节点，不会创建任何 standby 节点。primary 节点仍会被监控以检测故障，但由于没有随时可以接管的副本，恢复时间可能会因问题的性质而更长。此配置最适合用于开发环境、测试场景，或允许一定停机时间的非关键工作负载。
备用节点 vs 只读副本
在 Managed Postgres 中，备用节点和只读副本承担不同的职责，并且需要分别进行配置。
备用节点（standbys） 专门用于实现高可用性和自动故障转移。它们通过流式复制从主节点复制数据，并始终处于可在主节点发生故障时被提升为主节点的就绪状态。备用节点不会对外提供读查询服务。
只读副本（read replicas） 旨在扩展读负载能力。它们从对象存储中拉取 WAL（Write-Ahead Log）数据，在独立的网络环境中运行，并拥有各自的连接端点。只读副本允许你将读取流量从主节点分流出去，而不会影响其高可用性（HA）保证。
为什么备用节点不处理读查询
虽然有些数据库提供商会对外暴露可用于只读查询的热备用节点，但 Managed Postgres 刻意不这么做。允许在备用节点上执行读查询会削弱它们的主要用途：在主节点发生故障时，能够立即无缝接管。
主要有两个方面的考虑：
-
WAL 重放竞争：在写入压力较大的工作负载下，备用节点上的读查询会与 WAL 重放争夺系统资源。这种竞争可能导致较高的复制延迟，也就是备用节点落后于主节点。如果在备用节点存在明显延迟时发生故障切换，它将无法拥有最新数据，可能也无法干净地完成接管。
-
VACUUM 干扰：在备用节点上运行时间较长的读查询，可能会阻止主节点上的
VACUUM（以及AUTOVACUUM）清理死元组。PostgreSQL 无法删除任何副本上活动查询可能仍需访问的行。这会导致表膨胀，并随着时间推移造成性能下降。
通过让备用节点专注于故障切换，Managed Postgres 可以确保它们始终保持同步，并在发生故障时以最小的数据丢失和停机时间完成接管。若要进行读负载扩展，请改用读取副本。
处理故障
无论是否启用高可用性，所有托管的 Postgres 实例都会被持续监控以发现故障。在任何情况下，系统都会尝试自动进行故障自愈。
当有备用节点可用时，自动恢复会更快且更简单。系统通常会在几分钟内通过将备用节点提升为主节点来完成恢复。如果没有备用节点，恢复可能需要人工干预，从而显著延长停机时长。
