你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for PostgreSQL 通过预配物理分隔的主副本和备用副本支持高可用性。 此高可用性模型旨在确保提交的数据永远不会在故障期间丢失。 在高可用性 (HA) 设置中，数据同步提交到主服务器和备用服务器。 该模型设计为数据库不会成为软件体系结构中的单一故障点。
默认情况下，在大多数区域中，备用副本将部署到主副本的不同可用性区域（区域冗余）。 还可以在同一可用性区域（区域）内部署主副本和备用副本。
高可用性功能
备用副本部署在同一 VM 配置（包括 vCore、存储和网络设置）中，作为主服务器。
可以为现有数据库服务器添加可用性区域支持。
可以禁用高可用性，这会删除备用副本。
可以为主数据库服务器和备用数据库服务器选择可用性区域，以实现区域冗余高可用性。
停止、启动和重启等操作可在主数据库服务器和备用数据库服务器上同时执行。
主数据库服务器定期执行自动备份。 同时，备用副本会持续存档备份存储中的事务日志。 对于区域冗余服务器，备份数据存储在区域冗余存储（ZRS）上。 备份数据存储在本地冗余存储（LRS）上，用于未配置区域冗余的服务器、区内（单区）服务器，以及所在区域不支持可用性区域的服务器。
客户端始终连接到主数据库服务器的最终主机名。
对服务器参数做出的任何更改也会应用于备用副本。
可以重启服务器来获取任何静态服务器参数更改。
定期维护活动（例如次要版本升级）首先在备用服务器上进行。 为了减少停机时间，将备用节点提升为主节点，以确保在剩余节点进行维护任务时，工作负载可以继续运行。
注释
若要确保高可用性功能正常运行，请配置 max_replication_slots 和 max_wal_senders 服务器参数值。 高可用性需要 4 个来处理故障转移和无缝升级。 对于具有 5 个只读副本和 12 个逻辑复制槽的高可用性设置，请将 max_replication_slots 和 max_wal_senders 两个参数的值设为 21。 此配置是必要的，因为每个只读副本和逻辑复制槽都需要一个，再加上高可用性正常运行所需的四个。 有关max_replication_slots和max_wal_senders参数的更多信息，请参阅文档。
可用性区域支持类型
Azure Database for PostgreSQL 支持 区域冗余模型和区域模型 以实现高可用性配置。 这两种高可用性配置都支持自动故障转移功能，在计划内和计划外事件期间都不会丢失数据。
区域冗余。 区域冗余高可用性在具有自动故障转移功能的不同区域中部署备用副本。 区域冗余提供最高级别的可用性，但需要跨区域配置应用程序冗余。 出于此原因，当想要保护可用性区域级别故障以及可用性区域之间的延迟是可接受的时，请选择区域冗余。 尽管同步复制可能会对写入和提交造成一些延迟影响，但不会影响读取查询。 这种影响特定于工作负荷、选择的 SKU 类型和区域。
可以为主服务器和备用服务器选择区域和可用性区域。 备用副本服务器在同一区域内所选可用性区域中进行预配，其计算、存储和网络配置与主服务器相似。 数据文件和事务日志文件（也称为 WAL）存储在每个可用性区域中的本地冗余存储（LRS），自动存储 三个 数据副本。 区域冗余配置会在主服务器和备用服务器之间为整个堆栈提供物理隔离。
区域冗余选项仅在支持可用性区域的区域中可用。
以下项不支持区域冗余：
- 可突发计算层
- 具有单区域可用性的区域
同一可用区（区域性）。 如果希望在单个可用性区域中实现最高级别可用性，但拥有最低的网络延迟，请选择区域式部署。 可以选择区域和可用性区域来部署主数据库服务器。 备用副本服务器在同一可用性区域中自动进行预配和管理，其计算、存储和网络配置与主服务器相似。 区域式配置可防止数据库发生节点级故障，还有助于减少计划内和计划外停机事件期间的应用程序停机时间。 在同步模式下，主服务器中的数据将复制到备用副本。 如果主服务器发生任何中断，系统会自动切换到备用副本。
区域式部署选项适用于所有 Azure 区域，可在其中部署灵活服务器。
注释
区域和区域冗余部署模型在体系结构上的行为相同。 除非另有说明，否则以下各节中的各种讨论均适用。
从区域故障中恢复
区域冗余：Azure Database for PostgreSQL 会在 60-120 秒内自动故障转移到备用服务器，且无数据丢失。
区域：如果区域发生故障，主服务器和备用服务器都不可用。 若要从区域级别故障中恢复，可以使用备份执行时间点还原。 可以选择具有最新时间的自定义还原点来还原最新数据。 新的灵活服务器部署在另一个不受影响的区域中。 还原所需的时间取决于以前的备份和要恢复的事务日志量。
有关时间点还原的详细信息，请参阅 Azure Database for PostgreSQL - 灵活服务器中的备份和还原。
SLA
区域冗余模型提供更高的运行时间 SLA（服务级别协议）。 有关详细信息，请参阅 联机服务的 SLA。
没有高可用性的 Azure Database for PostgreSQL
尽管不建议这样做，但你可以在不启用高可用性的情况下配置灵活服务器。 对于配置不具有高可用性的灵活服务器，该服务提供本地冗余存储以及三个数据副本，以及内置的服务器复原能力，以自动重启崩溃的服务器并将服务器重新定位到另一个物理节点。 此配置提供的 运行时间 SLA 比具有高可用性的服务器低。 在计划内或计划外故障转移事件期间，如果服务器出现故障，服务会使用以下自动化过程维护服务器的可用性：
- 预配新的计算 Linux VM。
- 具有数据文件的存储映射到新的虚拟机。
- PostgreSQL 数据库引擎在新的虚拟机上联机。
下图显示了 VM 与存储故障之间的转换。
配置业务关键（高可用性）选项
可以通过两种方式配置高可用性（HA），即区域冗余 HA，将备用服务器置于不同的可用性区域中以实现最大区域复原，或者将备用服务器部署到主服务器所在的同一区域中的同一区域 HA，以最大程度地降低延迟。
“业务关键（高可用性）”部分提供了一个选项，用于创建具有区域冗余配置的备用 HA 服务器。 为了简化配置并确保区域复原，门户提供了一个 区域复原 选项，其中包含两个单选按钮：“已启用”和“禁用”。 选择“已启用”尝试在不同的可用性区域（区域冗余 HA 模式）中创建备用服务器。 如果区域不支持区域冗余 HA，则可以选中回退复选框，以改为启用同一区域（区域性）HA。
选中回退复选框时，系统会在同一区域中创建备用服务器。 如果区域容量以后可用，Azure 将自动将工作负荷从同一区域 HA 迁移到区域冗余 HA。 如果未选中复选框，区域容量不可用，HA 启用将失败。 此设计将区域冗余 HA 作为默认设置，同时为同区域 HA 提供可控回退，确保工作负载最终实现完整的区域弹性。
创建已启用可用性区域的 Azure Database for PostgreSQL
若要了解如何使用可用性区域创建 Azure Database for PostgreSQL 以实现高可用性，请参阅 快速入门：在 Azure 门户中创建 Azure Database for PostgreSQL。
可用性区域重新部署和迁移
若要了解如何在灵活服务器中启用或禁用区域冗余部署模型中的高可用性配置，请参阅 “在灵活服务器中管理高可用性”。
监视高可用性健康状况
Azure Database for PostgreSQL 中的高可用性（HA）运行状况监视持续概述了已启用 HA 的实例的运行状况和就绪情况。 此监视功能应用 Azure 的资源运行状况检查 （RHC） 框架来检测和警报可能影响数据库的故障转移准备情况或整体可用性的任何问题。 通过评估连接状态、故障转移状态和数据复制运行状况等关键指标，HA 运行状况监视可实现主动故障排除，并帮助维护数据库的运行时间和性能。
使用 HA 健康状态监控实现以下操作：
- 获取有关主要副本和备用副本健康状况的实时见解，状态指示器揭示潜在问题，例如性能退化或网络阻塞。
- 设置警报以便及时通知高可用性状态的任何更改，从而能够立即采取措施以解决潜在中断。
- 通过在影响数据库操作之前识别和解决问题来优化故障转移准备情况。
有关配置和解释 HA 运行状况的详细指南，请参阅 Azure Database for PostgreSQL 的高可用性（HA）运行状况监视。
高可用性限制
主服务器和备用服务器之间的复制是同步的。
不能将备用 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 扩展 文档。
不支持在专用（虚拟网络）和专用终结点的公共访问之间配置可用性区域。 您必须在虚拟网络中配置可用性区域（分布在同一区域内的可用性区域）或通过专用终结点实现公共访问。
只能在单个区域中配置可用性区域。 不能跨区域配置可用性区域。
高可用性组件和工作流
事务完成
应用程序事务触发的写入和提交首先记录到主服务器上的 WAL。 主服务器使用 Postgres 流式处理协议将这些日志流式传输到备用服务器。 当备用服务器存储保留日志时，主服务器会确认写入完成。 应用程序仅在收到确认后提交其事务。 此额外的往返增加了应用程序的延迟。 影响百分比取决于应用程序。 此确认过程不会等待日志应用于备用服务器。 备用服务器在恢复模式下处于恢复模式，直到它被提升。
健康检查
灵活的服务器运行状况监视会定期检查主服务器和备用服务器的运行状况。 多次 ping 后，如果运行状况监视检测到主服务器无法访问，该服务会启动自动故障转移到备用服务器。 健康监测算法使用多个数据点来避免误报事件。
故障转移模式
灵活服务器支持两种故障转移模式：计划的故障转移和计划外故障转移。 在这两种模式下，一旦复制中断，备用服务器就会在提升为主服务器之前运行恢复并打开以进行读/写。 使用新的主服务器终结点更新了自动 DNS 条目后，应用程序可以使用同一终结点连接到服务器。 在后台建立新的备用服务器，使应用程序可以保持连接。
高可用性状态
系统持续监视主服务器和备用服务器的运行状况。 它采取适当的行动来解决问题，包括触发故障转移到备用服务器。 下表列出了可能的高可用性状态：
| 状态 | 说明 |
|---|---|
| 正在初始化 | 正在创建新的备用服务器。 |
| 正在复制数据 | 创建备用服务器后，它会与主服务器进行通信。 |
| 健康 | 复制处于稳定状态且正常运行。 |
| 正在进行故障转移 | 数据库服务器正在故障转移到备用服务器。 |
| 正在删除备用服务器 | 正在删除备用服务器。 |
| 未启用 | 未启用高可用性。 |
注释
可以在创建服务器期间或以后启用高可用性。 如果在创建后阶段启用或禁用高可用性，请在主服务器活动较低时执行此作。
稳定状态操作
PostgreSQL 客户端应用程序使用数据库服务器名称连接到主服务器。 主服务器直接为应用程序读取提供服务。 同时，应用程序仅在主服务器和备用副本上保留日志数据后才会收到提交和写入的确认。 由于这种额外的往返，预计会增加应用程序写入和提交操作的延迟。 用户可以在门户中监视高可用性的运行状况。
- 客户端连接到灵活服务器并执行写入操作。
- 将更改复制到备用站点。
- 主服务器收到确认。
- 确认写入和提交操作。
高可用性服务器的时间点还原
对于配置高可用性的灵活服务器，系统将实时日志数据复制到备用服务器。 主服务器上的任何用户错误（例如意外删除表或不正确的数据更新）都会复制到备用副本。 因此，无法使用备用机制从此类逻辑错误中恢复。 若要从这类错误中恢复，必须从备份执行时间点还原。 通过使用灵活服务器的时间点还原功能，可以还原到错误发生前的时间。 新的数据库服务器将还原为区域性（单区域）灵活服务器，该服务器具有用户为配置高可用性的数据库提供的新服务器名称。 可以将还原的服务器用于多个用例：
使用恢复的服务器用于生产环境，并可选择性地在相同区域或相同区域的其他位置启用备用副本以实现高可用性。
如果要还原对象，请从还原的数据库服务器导出该对象并将其导入生产数据库服务器。
如果想要克隆数据库服务器以便进行测试和开发，或者出于任何其他目的想要进行还原，则可以执行时间点还原。
若要了解如何对灵活服务器执行时间点还原，请参阅灵活服务器的时间点还原。
故障转移支持
计划的故障转移
计划内停机事件包括 Azure 计划的定期软件更新和次要版本升级。 还可以使用计划的故障转移将主服务器返回到首选可用性区域。 配置高可用性时，这些作首先应用于备用副本，同时应用程序继续访问主服务器。 进程更新备用副本后，它会清空主服务器连接，并触发一个故障转移，该故障转移会将备用副本激活为具有相同数据库服务器名称的主服务器。 客户端应用程序将使用相同的数据库服务器名称重新连接到新的主服务器，并可以恢复其作。 此过程在与旧主服务器相同的区域中建立新的备用服务器。
小窍门
如果具有区域冗余灵活服务器，还可以使用计划的故障转移将主服务器返回到首选可用性区域，从而减少停机时间。 例如，主服务器在计划外故障转移后可能位于与应用程序不同的可用性区域中。 计划的故障转移过程将主服务器移回其原始区域，并在与旧主服务器相同的区域中建立新的备用服务器。
对于其他用户启动的操作（如扩展计算或扩展存储），该过程首先对备用服务器进行更改，然后再应用到主服务器。 目前，服务不会故障转移到备用服务器。 因此，当缩放操作在主服务器上运行时，应用程序会经历短暂的停机时间。
还可以使用此功能故障转移到备用服务器，同时能缩短停机时间。 例如，主服务器在计划外故障转移后可能位于与应用程序不同的可用性区域中。 需要将主服务器带回上一个区域，以便与应用程序并置。
执行此功能时，该过程首先准备备用服务器，以确保它赶上最近的事务，使应用程序能够继续执行读取和写入。 此过程会启用备用模式并断开到主节点的连接。 当进程在后台建立新的备用服务器时，应用程序可以继续写入主服务器。 下表描述了计划故障转移所涉及的步骤：
| Step | 说明 | 是否出现应用停机？ |
|---|---|---|
| 1 | 等待备用服务器赶上主服务器。 | 否 |
| 2 | 内部监视系统启动故障转移工作流。 | 否 |
| 3 | 当备用服务器接近主日志序列号 (LSN) 时，应用程序写入操作会被拦截。 | 是的 |
| 4 | 备用服务器升级为独立服务器。 | 是的 |
| 5 | 以新备用服务器的 IP 地址更新 DNS 记录。 | 是的 |
| 6 | 应用程序重新连接新的主服务器并恢复其读/写操作。 | 否 |
| 7 | 已建立新的备用服务器。 对于区域冗余服务器，新服务器位于另一个区域中。 | 否 |
| 8 | 备用服务器开始（从 Azure Blob）恢复在建立期间丢失的日志。 | 否 |
| 9 | 在主服务器和备用服务器之间建立稳定状态。 | 否 |
| 10 | 计划的故障转移过程已完成。 | 否 |
应用程序停机时间从步骤 3 开始，可以在步骤 5 后恢复作。 其余步骤在后台进行，但不会影响应用程序写入和提交。
小窍门
借助灵活服务器，你可以在喜欢的一天内（数据库上的活动预计较少的情况下）选择 60 分钟的时段来安排 Azure 启动的维护活动。 Azure 维护任务（例如修补或次要版本升级）在该时段内发生。 如果未选择自定义窗口，系统将为服务器分配一小时时段（下午 11 点到 7 点）。 对于配置了可用性区域的灵活服务器，这些 Azure 发起的维护活动也会在备用副本上执行。
有关可能的计划内停机事件的列表，请参阅计划内停机事件。
计划外故障转移
由于基础硬件故障、网络问题和软件 bug 等意外中断，可能会发生计划外停机。 如果配置了高可用性的数据库服务器意外关闭，进程将激活备用副本，客户端可以恢复其作。 如果未配置高可用性（HA），并且重启尝试失败，该过程会自动预配新的数据库服务器。 虽然无法避免计划外停机，但灵活服务器可以通过自动执行恢复作来缓解停机时间，而无需人工干预。
有关计划外故障转移和停机时间（包括可能的方案）的信息，请参阅计划外停机缓解。
强制故障转移
可以使用强制故障转移进行 故障转移测试，以便在运行生产工作负荷时模拟计划外中断方案，并观察应用程序的停机时间。 主服务器无响应时，也可以使用强制故障转移。
强制故障转移会导致主服务器停止运行，并启动可在其中执行备用服务器升级操作的故障转移工作流。 完成恢复过程并最终提交数据后，备用服务器将升级为主服务器。 DNS 记录将会更新，且应用程序可以连接到升级后的主服务器。 在后台建立新的备用服务器时，应用程序可以继续写入主服务器，而不会影响运行时间。
下表描述了强制故障转移期间的步骤：
| Step | 说明 | 是否出现应用停机？ |
|---|---|---|
| 1 | 收到故障转移请求后不久，主服务器将停止。 | 是的 |
| 2 | 主服务器关闭时，应用程序出现停机。 | 是的 |
| 3 | 内部监视系统检测到故障，并启动到备用服务器的故障转移。 | 是的 |
| 4 | 备用服务器在完全升级为独立服务器之前进入恢复模式。 | 是的 |
| 5 | 故障转移过程会等待备用恢复完成。 | 是的 |
| 6 | 服务器启动后，进程会使用相同的主机名更新 DNS 记录，但使用备用服务器的 IP 地址。 | 是的 |
| 7 | 应用程序可以重新连接到新的主服务器并恢复操作。 | 否 |
| 8 | 在首选区域中建立备用服务器。 | 否 |
| 9 | 备用服务器开始（从 Azure Blob）恢复在建立期间丢失的日志。 | 否 |
| 10 | 在主服务器和备用服务器之间建立稳定状态。 | 否 |
| 11 | 强制故障转移过程已完成。 | 否 |
应用程序停机在步骤 1 后开始，一直持续到步骤 6 完成。 其他步骤在后台运行，不会影响应用程序写入和提交。
重要
端到端故障转移过程包括 (a) 在主故障后故障转移到备用服务器，以及 (b) 建立处于稳定状态的新备用服务器。 由于您的应用程序在故障转移到备用完成之前会经历停机，应从应用程序/客户端的角度测量停机时间，而不是整个端到端的故障转移过程。
执行强制故障转移时的注意事项
整个端到端运行时间可能比应用程序实际停机时间更长。
重要
务必从应用程序的角度观察故障时间！
请勿持续执行即时故障转移。 在两次故障转移之间等待至少 15-20 分钟，这样有助于充分构建新备用服务器。
在低活动期间执行强制故障转移，以缩短停机时间。
故障转移后 PostgreSQL 统计信息的最佳做法
PostgreSQL 故障转移后，要维持最佳数据库性能，需要了解 pg_statistic 和 pg_stat_* 视图的不同角色。 表 pg_statistic 存储优化器统计信息，这对查询规划器至关重要。 这些统计信息包括表中的数据分布，在故障转移后保持不变，以确保查询规划器可以基于准确的历史数据分布信息继续有效地优化查询执行。
相比之下，pg_stat_* 视图提供扫描次数、读取的元组数和更新次数等运行时活动统计信息，它们存储在内存中，故障转移时会重置。 例如 pg_stat_user_tables，跟踪用户定义的表的活动。 此重置会准确反映新的主节点的运行状态，但也意味着历史活动指标的丢失，这些指标可能提供有关自动清理进程和其他操作效率的信息。
鉴于此区别，可以考虑在 PostgreSQL 故障转移后运行 ANALYZE 。 此操作使用新的清理 (vacuum) 活动统计信息更新 pg_stat_* 数据（例如 pg_stat_user_tables），为自动清理 (autovacuum) 过程提供支持，进而确保数据库在新角色中仍保持最佳性能。 此主动步骤弥合了保留基本优化器统计信息与刷新活动指标之间的差距，以与数据库的当前状态保持一致。