Azure Database for PostgreSQL 中的高可用性（可靠性）

本文介绍 Azure Database for PostgreSQL 中的高可用性，其中包括 可用性区域 和 跨区域恢复和业务连续性。 有关 Azure 中可靠性的更详细概述，请参阅 Azure 可靠性。

Azure Database for PostgreSQL 通过预配物理隔离的主副本和备用副本（在同一可用性区域（区域）内或跨可用性区域（区域冗余）来支持高可用性。 此高可用性模型旨在确保提交的数据永远不会在故障期间丢失。 在高可用性 (HA) 设置中，数据同步提交到主服务器和备用服务器。 该模型设计为数据库不会成为软件体系结构中的单一故障点。 有关高可用性和可用性区域支持的详细信息，请参阅可用性区域支持。

可用性区域支持

可用性区域 是每个 Azure 区域内物理上独立的数据中心群组。 当某个区域发生故障时，服务可以切换到其他可用的区域。

Azure Database for PostgreSQL 支持 区域冗余模型和区域模型 以实现高可用性配置。 这两种高可用性配置都支持自动故障转移功能，在计划内和计划外事件期间都不会丢失数据。

• 区域冗余。 区域冗余高可用性在具有自动故障转移功能的不同区域中部署备用副本。 区域冗余提供最高级别的可用性，但需要跨区域配置应用程序冗余。 出于此原因，当想要保护可用性区域级别故障以及可用性区域之间的延迟是可接受的时，请选择区域冗余。 尽管同步复制可能会对写入和提交造成一些延迟影响，但不会影响读取查询。 这种影响特定于工作负荷、选择的 SKU 类型和区域。

  可以为主服务器和备用服务器选择区域和可用性区域。 备用副本服务器在同一区域内所选可用性区域中进行预配，其计算、存储和网络配置与主服务器相似。 数据文件和事务日志文件（也称为 WAL）存储在每个可用性区域中的本地冗余存储（LRS），自动存储 三个 数据副本。 区域冗余配置会在主服务器和备用服务器之间为整个堆栈提供物理隔离。

  

区域冗余选项仅在支持可用性区域的区域中可用。

不支持区域冗余：

• 可突发计算层

• 具有单区域可用性的区域

• 区域式。 如果希望在单个可用性区域中实现最高级别可用性，但拥有最低的网络延迟，请选择区域式部署。 可以选择区域和可用性区域来部署主数据库服务器。 备用副本服务器在同一可用性区域中自动进行预配和管理，其计算、存储和网络配置与主服务器相似。 区域式配置可防止数据库发生节点级故障，还有助于减少计划内和计划外停机事件期间的应用程序停机时间。 在同步模式下，主服务器中的数据将复制到备用副本。 如果主服务器发生任何中断，服务器会自动故障转移到备用副本。

  

区域式部署选项适用于所有 Azure 区域，可在其中部署灵活服务器。

在门户中配置区域复原能力

可以通过两种方式配置高可用性（HA），即区域冗余 HA，将备用服务器置于不同的可用性区域中以实现最大复原能力，或者将备用服务器部署到主服务器所在的同一区域中的同一区域 HA，以最大程度地降低延迟。

为了简化配置并确保区域复原，门户提供了一个区域复原选项，其中包含两个单选按钮：“已启用”和“禁用”。 选择“已启用”尝试在不同的可用性区域（区域冗余 HA 模式）中创建备用服务器。 如果区域不支持区域冗余 HA，则可以选中回退复选框（下图中突出显示）以改为启用同一区域 HA。

选中回退复选框时，系统会在同一区域中创建备用服务器，并在维护时段内触发自动迁移工作流，在容量可用后将其移动到其他区域。 如果未选中复选框，区域容量不可用，HA 启用将失败。 此设计强制实施区域冗余 HA 作为默认值，同时为同一区域 HA 提供受控回退，确保工作负荷最终实现完全区域复原，而无需手动干预。

高可用性功能

• 备用副本部署在同一 VM 配置（包括 vCore、存储和网络设置）中，作为主服务器。

• 可以为现有数据库服务器添加可用性区域支持。

• 可以通过禁用高可用性来删除备用副本。

• 可以为主数据库服务器和备用数据库服务器选择可用性区域，以实现区域冗余可用性。

• 停止、启动和重启等操作可在主数据库服务器和备用数据库服务器上同时执行。

• 在区域冗余和区域模型中，主数据库服务器定期执行自动备份。 同时，备用副本会持续存档备份存储中的事务日志。 如果区域支持可用性区域，备份数据会存储在区域冗余存储 (ZRS) 中。 在不支持可用性区域的区域中，备份数据存储在本地冗余存储 (LRS) 中。

• 客户端始终连接到主数据库服务器的最终主机名。

• 对服务器参数做出的任何更改也会应用于备用副本。

• 可以重启服务器以选取任何静态服务器参数更改。

• 定期维护活动（例如次要版本升级）首先在备用服务器上进行。 为了减少停机时间，备用服务器将提升为主节点，以便在剩余节点上应用维护任务时工作负荷可以继续运行。

监视高可用性运行状况

Azure Database for PostgreSQL 中的高可用性（HA）运行状况监视持续概述了已启用 HA 的实例的运行状况和就绪情况。 此监视功能应用 Azure 的资源运行状况检查 （RHC） 框架来检测和警报可能影响数据库的故障转移准备情况或整体可用性的任何问题。 通过评估连接状态、故障转移状态和数据复制运行状况等关键指标，HA 运行状况监视可实现主动故障排除，并帮助维护数据库的运行时间和性能。

使用 HA 运行状况监视可以：

• 获取对主要副本和备用副本运行状况的实时见解，并显示潜在问题的状态指示器，例如性能下降或网络阻塞。
• 设置有关 HA 状态中任何更改的及时通知的警报，以便可以立即采取措施来解决潜在的中断。
• 通过在影响数据库操作之前识别和解决问题来优化故障转移准备情况。

有关配置和解释 HA 运行状况的详细指南，请参阅 Azure Database for PostgreSQL 的高可用性（HA）运行状况监视。

高可用性限制

• 由于同步复制到备用服务器，尤其是使用区域冗余配置，应用程序可能会遇到提升的写入和提交延迟。

• 不能将备用副本用于读取查询。

• 根据主服务器上的工作负荷和活动，故障转移过程可能需要超过 120 秒的时间，因为备用副本需要恢复才能升级它。

• 备用服务器通常以 40 MB/秒的速度恢复 WAL 文件。 对于更大的版本，此速率可以增加到 200 MB/秒。 如果工作负载超出了此限制，你都可能会遇到在故障转移期间或建立新的备用副本后恢复完成时间延长的情况。

• 重启主数据库服务器也会重启备用副本。

• 无法配置额外的备用服务器。

• 无法在托管维护时段内计划客户启动的管理任务。

• 计划的事件（例如，缩放计算和缩放存储）首先在备用服务器上发生，然后在主服务器上发生。 对于这些计划内操作，服务器目前不会进行故障转移。

• 如果在启用了 HA 的灵活服务器上配置了逻辑解码或逻辑复制。

  • 在 PostgreSQL 16 及更早版本中，默认情况下，在故障转移后，逻辑复制槽不会保留在备用服务器上。
  • 若要确保逻辑复制在故障转移后继续正常运行，需要启用 pg_failover_slots 扩展并配置支持设置，例如 hot_standby_feedback = on。
  • 从 PostgreSQL 17 开始，本机支持槽同步。 如果启用正确的 PostgreSQL 配置（sync_replication_slots，）， hot_standby_feedback则故障转移后会自动保留逻辑复制槽，无需扩展。
  • 有关设置步骤和先决条件，请参阅 PG_Failover_Slots扩展 文档。

• 不支持在专用（虚拟网络）和专用终结点的公共访问之间配置可用性区域。 必须在虚拟网络中配置可用性区域（跨区域中的可用性区域）或具有专用终结点的公共访问。

• 只能在单个区域中配置可用性区域。 不能跨区域配置可用性区域。

SLA

• 区域模型为 SLA 提供大约 99 个%的运行时间。

• 区域冗余模型为 SLA 提供大约 99%的运行时间。

创建启用了可用性区域的 Azure Database for PostgreSQL

若要了解如何使用可用性区域创建 Azure Database for PostgreSQL 以实现高可用性，请参阅 快速入门：在 Azure 门户中创建 Azure Database for PostgreSQL。

可用性区域重新部署和迁移

若要了解如何在灵活服务器中启用或禁用区域冗余部署模型中的高可用性配置，请参阅 “在灵活服务器中管理高可用性”。

高可用性组件和工作流

事务完成

应用程序事务触发的写入并将第一个日志提交到主服务器上的 WAL。 主服务器使用 Postgres 流式处理协议将这些日志流式传输到备用服务器。 当备用服务器存储保留日志时，主服务器会确认写入完成。 应用程序仅在此确认后提交其事务。 此额外的往返将延迟添加到应用程序。 影响百分比取决于应用程序。 此确认过程不会等待日志应用于备用服务器。 备用服务器保持恢复模式，直到升级。

健康检查

灵活的服务器运行状况监视会定期检查主服务器和备用服务器的运行状况。 多次 ping 后，如果运行状况监视检测到主服务器无法访问，该服务将启动自动故障转移到备用服务器。 运行状况监视算法使用多个数据点来避免误报情况。

故障转移模式

灵活服务器支持两种故障转移模式：计划的故障转移和计划外故障转移。 在这两种模式下，一旦复制中断，备用服务器将运行恢复，然后作为主服务器升级并打开进行读/写。 使用新的主服务器终结点更新了自动 DNS 条目后，应用程序可以使用同一终结点连接到服务器。 在后台建立新的备用服务器，使应用程序可以保持连接。

高可用性状态

系统持续监视主服务器和备用服务器的运行状况。 它采取适当的作来解决问题，包括触发故障转移到备用服务器。 下表列出了可能的高可用性状态：

稳定状态操作

PostgreSQL 客户端应用程序使用数据库服务器名称连接到主服务器。 主服务器直接为应用程序读取提供服务。 同时，应用程序仅在主服务器和备用副本上保留日志数据后才会收到提交和写入的确认。 由于这种额外的往返，预计会增加应用程序写入和提交操作的延迟。 用户可以在门户中监视高可用性的运行状况。

1. 客户端连接到灵活服务器并执行写入操作。
2. 将更改复制到备用站点。
3. 主服务器收到确认。
4. 确认写入和提交。

高可用性服务器的时间点还原

对于配置高可用性的灵活服务器，系统将实时日志数据复制到备用服务器。 主服务器上的任何用户错误（例如意外删除表或不正确的数据更新）都会复制到备用副本。 因此，无法使用备用服务器从此类逻辑错误中恢复。 若要从此类错误中恢复，必须从备份执行时间点还原。 通过使用灵活服务器的时间点还原功能，可以还原到错误发生前的时间。 新的数据库服务器将还原为单区域灵活服务器，该服务器具有用户为配置高可用性的数据库提供的新服务器名称。 可以将还原的服务器用于多个用例：

• 使用还原的服务器进行生产，还可以选择在同一区域或同一区域中的另一个区域中启用备用副本的高可用性。

• 如果要还原对象，请从还原的数据库服务器导出该对象并将其导入生产数据库服务器。

• 如果想要克隆数据库服务器以便进行测试和开发，或者出于任何其他目的想要进行还原，则可以执行时间点还原。

若要了解如何对灵活服务器执行时间点还原，请参阅灵活服务器的时间点还原。

故障转移支持

计划的故障转移

计划内停机事件包括 Azure 计划的定期软件更新和次要版本升级。 还可以使用计划的故障转移将主服务器返回到首选可用性区域。 配置高可用性时，这些作首先应用于备用副本，同时应用程序继续访问主服务器。 进程更新备用副本后，它会清空主服务器连接，并触发一个故障转移，该故障转移会将备用副本激活为具有相同数据库服务器名称的主服务器。 客户端应用程序将使用相同的数据库服务器名称重新连接到新的主服务器，并可以恢复其作。 此过程在与旧主服务器相同的区域中建立新的备用服务器。

对于其他用户启动的作（如缩放计算或缩放存储），该过程首先对备用服务器应用更改，然后再应用主数据库。 目前，服务不会故障转移到备用服务器。 因此，虽然缩放作在主服务器上运行，但应用程序遇到短暂的停机时间。

还可以使用此功能故障转移到备用服务器，同时能缩短停机时间。 例如，主服务器在计划外故障转移后可能位于与应用程序不同的可用性区域中。 需要将主服务器带回上一个区域，以便与应用程序并置。

执行此功能时，该过程首先准备备用服务器，以确保它赶上最近的事务，使应用程序能够继续执行读取和写入。 此过程将提升备用服务器，并将连接断断到主节点的连接。 当进程在后台建立新的备用服务器时，应用程序可以继续写入主服务器。 下表描述了计划内故障转移所涉及的步骤：

应用程序停机时间从步骤 3 开始，可以在步骤 5 后恢复作。 其余步骤在后台进行，但不会影响应用程序写入和提交。

有关可能的计划内停机事件的列表，请参阅计划内停机事件。

计划外故障转移

由于基础硬件故障、网络问题和软件 bug 等意外中断，可能会发生计划外停机。 如果配置了高可用性的数据库服务器意外关闭，进程将激活备用副本，客户端可以恢复其作。 如果未配置高可用性（HA），并且重启尝试失败，该过程会自动预配新的数据库服务器。 虽然无法避免计划外停机，但灵活服务器可以通过自动执行恢复作来缓解停机时间，而无需人工干预。

有关计划外故障转移和停机时间（包括可能的方案）的信息，请参阅计划外停机缓解。

故障转移测试（强制故障转移）

使用强制故障转移，可以在运行生产工作负荷时模拟计划外中断方案，并观察应用程序停机时间。 主服务器无响应时，也可以使用强制故障转移。

强制故障转移会导致主服务器停止运行，并启动可在其中执行备用服务器升级操作的故障转移工作流。 一旦备用服务器完成恢复过程，直到最后一个提交的数据，它就会提升为主服务器。 DNS 记录将会更新，且应用程序可以连接到升级后的主服务器。 在后台建立新的备用服务器时，应用程序可以继续写入主服务器，而不会影响运行时间。

下表描述了强制故障转移期间的步骤：

应用程序停机在步骤 1 后开始，一直持续到步骤 6 完成。 其他步骤在后台运行，不会影响应用程序写入和提交。

执行强制故障转移时的注意事项

• 整个端到端作时间可能比应用程序实际停机时间更长。

  重要

  务必从应用程序的角度观察故障时间！

• 请勿持续执行即时故障转移。 等待故障转移之间的至少 15-20 分钟，以便完全建立新的备用服务器。

• 在低活动期间执行强制故障转移，以减少停机时间。

故障转移后 PostgreSQL 统计信息的最佳做法

在 PostgreSQL 故障转移后，保持最佳数据库性能涉及了解 pg_statistic 和 pg_stat_* 表的不同角色。 表 pg_statistic 存储优化器统计信息，这对查询规划器至关重要。 这些统计信息包括表中的数据分布，在故障转移后保持不变，以确保查询规划器可以基于准确的历史数据分布信息继续有效地优化查询执行。

相反，记录 pg_stat_* 活动统计信息（例如扫描次数、元组读取和更新）在故障转移时重置的表。 此类表的一个示例是 pg_stat_user_tables，该表跟踪用户定义的表的活动。 此重置准确反映了新主节点的作状态，但也意味着历史活动指标的丢失，这些指标可能会通知 autovacuum 过程和其他运营效率。

鉴于此区别，请在 PostgreSQL 故障转移后运行 ANALYZE 。 此操作使用新的活动统计信息更新 pg_stat_* 表（例如 pg_stat_user_tables），为自动清理进程提供帮助并确保数据库性能在其新角色中保持最佳。 此主动步骤弥合了保留基本优化器统计信息与刷新活动指标之间的差距，以与数据库的当前状态保持一致。

区域关闭体验

区域：若要从区域级别故障中恢复，可以使用备份 执行时间点还原 。 可以选择具有最新时间的自定义还原点来还原最新数据。 新的灵活服务器部署在另一个不受影响的区域中。 还原所需的时间取决于以前的备份和要恢复的事务日志量。

有关时间点还原的详细信息，请参阅 Azure Database for PostgreSQL - 灵活服务器中的备份和还原。

区域冗余：灵活服务器在 60-120 秒内自动故障转移到备用服务器，不会丢失数据。

没有可用性区域的配置

尽管不建议这样做，但你可以在不启用高可用性的情况下配置灵活服务器。 对于配置不具有高可用性的灵活服务器，该服务提供本地冗余存储，其中包含三个数据副本、区域冗余备份（在受支持的区域中），以及内置的服务器复原能力，以便自动重启崩溃的服务器并将服务器重新定位到另一个物理节点。 此配置提供 99.9%的运行时间 SLA。 在计划内或计划外故障转移事件期间，如果服务器出现故障，服务会使用以下自动化过程维护服务器的可用性：

1. 预配新的计算 Linux VM。
2. 具有数据文件的存储映射到新的虚拟机。
3. PostgreSQL 数据库引擎在新的虚拟机上联机。

下图显示了 VM 与存储故障之间的转换。

跨区域灾难恢复和业务连续性

如果发生区域范围的灾难，Azure 可以使用另一个区域，通过灾难恢复提供区域或大型地理灾难的保护。 有关 Azure 灾难恢复体系结构的详细信息，请参阅 Azure 到 Azure 的灾难恢复体系结构。

灵活服务器提供在计划内和计划外停机事件期间保护数据并减少任务关键型数据库的停机时间的功能。 灵活服务器基于 Azure 基础结构构建，提供可靠的复原能力和可用性，具有业务连续性功能，提供故障保护、解决恢复时间要求，并降低数据丢失的风险。 在构建应用程序时，请考虑故障时间容忍度（恢复时间目标（RTO）和数据丢失暴露-恢复点目标（RPO）。 例如，与测试数据库相比，业务关键数据库具有更严格的正常运行时间要求。

多区域地理位置中的灾难恢复

异地冗余备份和还原

异地冗余备份和还原使你能够在发生灾难时在不同的区域中还原服务器。 它还能在一年的时间里为备份对象提供至少 99.99999999999999%（16 个 9）的持久性。

只能在创建服务器时配置异地冗余备份。 使用异地冗余备份配置服务器时，备份数据和事务日志将通过存储复制异步复制到配对区域。

有关异地冗余备份和还原的详细信息，请参阅异地冗余备份和还原。

只读副本

可以部署跨区域只读副本，以保护数据库免受区域级故障的影响。 只读副本是使用 PostgreSQL 的物理复制技术异步更新的，它们可能会滞后主要副本。 常规用途和内存优化计算层支持只读副本。

如需详细了解只读副本的功能和注意事项，请参阅只读副本。

服务中断检测、通知和管理

如果使用异地冗余备份配置服务器，可以在配对区域中执行异地还原。 系统会预配新服务器，并将其恢复到复制到该区域的最后一个可用数据。

还可以使用跨区域只读副本。 如果发生区域故障，可以通过将只读副本提升为独立的可读写服务器来执行灾难恢复作。 RPO 预计最多为 5 分钟（数据丢失），除非 RPO 在发生故障时可能接近复制延迟时出现严重的区域故障。

有关区域性灾难后计划外停机缓解和恢复的详细信息，请参阅计划外停机缓解。

相关内容

• Azure Database for PostgreSQL 文档
• Azure 中的可靠性