你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for PostgreSQL 灵活服务器中的高可用性概念
适用于：
Azure Database for PostgreSQL 灵活服务器
Azure Database for PostgreSQL 灵活服务器提供了具有自动故障转移功能的高可用性配置。 高可用性解决方案旨在确保提交的数据永远不会由于故障而丢失，且数据库不会成为体系结构中的单一故障点。 配置高可用性后，灵活服务器会自动预配和管理备用副本。 使用 PostgreSQL 流式复制以同步模式将预写日志 (WAL) 流式传输到副本。 有两种高可用性体系结构模型：
- 区域冗余高可用性：此选项跨一个区域内的多个可用性区域提供基础结构的完全隔离和冗余。 它提供最高级别的可用性，但需要你跨可用性区域配置应用程序冗余。 如果希望免受可用性区域故障的影响，则区域冗余是首选方法。 但应该考虑到跨 AZ 同步写入增加的延迟。 对于持续时间较短的事务的应用程序，这种延迟更为明显。 区域冗余高可用性在部分 Azure 区域中可用，这些区域支持多个可用性区域。 此配置中提供 99.99% 的 SLA 运行时间。
- 相同区域高可用性：此选项提供具有较低网络延迟的基础结构冗余，因为主服务器和备用服务器将位于同一可用性区域中。 它提供高可用性，且无需跨区域配置应用程序冗余。 如果希望在单个可用性区域中实现最高级别可用性，则首选相同区域高可用性。 此选项可降低延迟影响，但会导致应用程序容易受到区域故障的影响。 相同区域高可用性在所有可以部署灵活服务器的 Azure 区域中可用。 此配置中提供 99.95% 的 SLA 运行时间。
在计划内/外事件过程中，高可用性配置可实现自动故障转移功能，而不会发生数据丢失（即 RPO=0）。 例如，用户启动的缩放计算操作属于计划内故障转移，即使计划外事件是指基础硬件和软件故障、网络故障和可用性区域故障等故障。
注意
这两种高可用性部署模型在体系结构上行为相同。 除非另有说明，否则以下各部分中的各种讨论均适用于这两者。
高可用性体系结构
如前所述，Azure Database for PostgreSQL 灵活服务器支持两种高可用性部署模型：区域冗余 HA 和相同区域 HA。 在这两种部署模型中，当应用程序提交事务时，事务日志（预写日志，也称为 WAL）将会写入数据/日志磁盘，并且还会在“同步”模式下复制到备用服务器。 在备用服务器上保留日志后，事务会被视为已提交，并向应用程序发送确认。 备用服务器始终处于应用事务日志的恢复模式。 但主服务器不会等待备用服务器应用这些日志记录。 在繁重的事务工作负荷下，副本服务器可能会落后，但通常会随着工作负载吞吐量的波动赶上主服务器。
区域冗余高可用性
这种高可用性部署使灵活服务器能够在各可用性区域高度可用。 可以为主服务器和备用服务器选择区域、可用性区域。 备用副本服务器在同一区域的选定可用性区域中进行预配，其计算、存储和网络配置与主服务器相似。 数据文件和事务日志文件（预写日志，也称为 WAL）存储在每个可用性区域内的本地冗余存储 (LRS) 中，该存储可自动存储三个数据副本。 这会在主服务器和备用服务器之间为整个堆栈提供物理隔离。
注意
并非所有区域都支持可用性区域来部署区域冗余高可用性。 请参阅此 Azure 区域列表。
自动备份会定期从主数据库服务器执行，而事务日志会持续从备用副本存档到备份存储。 备份数据存储在区域冗余存储上。
相同区域高可用性
这种高可用性部署模式使灵活服务器能够在同一可用性区域高度可用。 这在所有区域都受支持，包括不支持可用性区域的区域。 可以选择区域和可用性区域来部署主数据库服务器。 备用服务器在同一区域的相同可用性区域中自动进行预配和管理，其计算、存储和网络配置与主服务器类似。 数据文件和事务日志文件（预写日志，也称为 WAL）存储在本地冗余存储中，该存储可自动存储为三个同步数据副本（每个副本用于主服务器和备用服务器）。 这会在同一可用性区域内的主服务器和备用服务器之间为整个堆栈提供物理隔离。
自动备份会定期从主数据库服务器执行，而事务日志会持续从备用副本存档到备份存储。 如果该区域支持可用性区域，则备份数据将存储在区域冗余存储 (ZRS) 上。 在不支持可用性区域的区域中，备份数据将存储在本地冗余存储 (LRS) 上。
组件和工作流
事务完成
应用程序事务触发的写入和提交首先记录到主服务器上的 WAL。 然后，使用 Postgres 流式传输协议流式传输到备用服务器。 日志保存在备用服务器存储后，主服务器将确认写入完成。 只有此时，应用程序才会确认写入。 这种额外的往返会导致应用程序的延迟增大。 影响大小取决于应用程序。 此确认过程不会等待日志在备用服务器上应用完成。 备用服务器在升级之前始终处于恢复模式。
运行状况检查
灵活服务器部署有运行状况监视，以定期检查主要和备用服务器的运行状况。 如果检测到在多次 ping 操作后仍无法访问主服务器，它会决定是否启动自动故障转移。 该算法基于多个数据点，以避免任何误报。
故障转移模式
有两种故障转移模式。
对于计划内故障转移（例如维护时段期间），即在主要连接已断开的已知状态下触发故障转移，在断开复制前执行干净关闭。 你还可以使用它来将主服务器重新引入首选 AZ。
对于计划外故障转移（例如主服务器节点故障），主服务器会立即受限，因此所有进行中的事务都会丢失并且应用程序会重试这些事务。
在这两种故障转移模式中，断开复制后，备用服务器运行恢复，然后升级为主服务器，并打开以进行读/写。 通过使用新主服务器终结点更新自动 DNS 条目，应用程序可以使用同一服务器终结点连接到服务器。 在后台建立新的备用服务器，不会阻止应用程序连接。
故障时间
在所有情况下，你都必须观测应用程序端/客户端的所有故障时间。 DNS 更新完毕时，应用程序即可在故障转移后重新建立连接。 我们还会考虑其他方面，包括在限制写入前对主服务器和备用服务器进行 LSN 比较。 但对于计划外故障转移，在某些情况下，由于在打开以进行读/写之前要恢复大量日志，备用服务器所需时间可能会超过 2 分钟。
监视高可用性
主服务器和备用服务器的运行状况会被持续监视，将采取相应的措施来解决问题，其中包括触发到备用服务器的故障转移。 下面是概述页上报告的高可用性状态列表：
| 状态 | 说明 |
|---|---|
| 正在初始化 | 正在创建新的备用服务器。 |
| 正在复制数据 | 创建备用服务器后，它会与主服务器进行通信。 |
| 正常运行 | 复制处于稳定状态且正常运行。 |
| 正在进行故障转移 | 数据库服务器正在故障转移到备用服务器。 |
| 正在删除备用服务器 | 正在删除备用服务器。 |
| 未启用 | 未启用区域冗余高可用性。 |
注意
可以在创建服务器期间启用高可用性，也可以随后启用。 如果在创建后阶段启用或禁用高可用性，则建议在主服务器活动较少时执行该操作。
稳定状态操作
PostgreSQL 客户端应用程序使用 DB 服务器名称连接到主服务器。 应用程序读取操作直接从主服务器进行，而只有在主服务器和备用副本上保存了日志数据后，才会向应用程序确认提交和写入操作。 由于这种额外的往返，预计会增加应用程序写入和提交操作的延迟。 你可以在门户上监视高可用性的运行状况。
- 客户端连接到灵活服务器并执行写入操作。
- 更改将复制到备用站点。
- 主服务器收到确认。
- 确认写入/提交操作。
故障转移进程 - 计划内停机时间
计划内停机事件包括 Azure 计划的定期软件更新和次要版本升级。 当配置为高可用性时，这些操作首先应用于备用副本，同时应用程序将继续访问主服务器。 更新备用副本后，主服务器连接将断开，并触发故障转移，这会激活备用副本，使其成为具有相同数据库服务器名称的主服务器。 客户端应用程序必须使用相同的数据库服务器名称重新连接到新的主服务器，并可以恢复其操作。 新的备用服务器将与旧的主服务器建立在同一区域中。
对于其他用户启动的操作（例如缩放计算或缩放存储），更改将首先应用于备用服务器，然后再应用于主服务器。 目前，该服务不会故障转移到备用服务器，因此，在主服务器上执行缩放操作期间，应用程序将会出现短暂的故障时间。
通过托管维护时段减少计划内停机时间
借助灵活服务器，你可以在喜欢的一天内（数据库上的活动预计较少的情况下）选择 60 分钟的时段来安排 Azure 启动的维护活动。 Azure 维护任务（例如修补或次要版本升级）将在维护时段进行。 如果未选择自定义窗口，则将为服务器选择系统分配的且介于本地时间晚上 11 点至早上 7 点之间的 1 小时时段。
对于配置为高可用性的灵活服务器，这些维护活动将首先在备用副本上执行，然后服务才会故障转移到应用程序可以重新连接的备用服务器上。
故障转移进程 - 计划外停机时间
- 计划外中断包括影响数据库可用性的软件 bug 或基础结构组件故障。 当主服务器不可用时，监视系统会检测到该服务器，并启动故障转移过程。 此过程包含几秒钟的等待时间，目的在于确保并非误报。 断开到备用副本的复制，并将激活备用副本作为主数据库服务器。 这包括用于恢复任何残留 WAL 文件的备用副本。 完全恢复后，将以备用服务器的 IP 地址更新同一终结点的 DNS。 然后，客户端可以使用相同的连接字符串重新连接到数据库服务器，并恢复其操作。
注意
配置了区域冗余高可用性的灵活服务器提供的恢复点目标 (RPO) 为零（无数据丢失）。 在典型情况下，恢复时间目标 (RTO) 应小于 120 秒。 不过，根据发生故障转移时主数据库服务器中的活动，故障转移可能需要更长时间。
在故障转移后，当预配新的备用服务器时（通常需要 5 到 10 分钟），应用程序仍可连接到主服务器，并继续执行读取/写入操作。 备用服务器将在建立后开始恢复在故障转移后生成的日志。
- 主数据库服务器关闭，客户端失去数据库连接。
- 备用服务器将激活成为新的主服务器。 客户端使用相同的连接字符串连接到新的主服务器。 使客户端应用程序位于与主数据库服务器相同的区域中可以降低延迟并提高性能。
- 备用服务器建立在与旧主服务器相同的区域中，并启动流式复制。
- 建立稳定状态的复制后，客户端应用程序提交和写入操作将在这两个站点上保存数据后得到确认。
按需故障转移
灵活服务器提供了两种方法，用于执行到备用服务器的按需故障转移。 若要测试故障转移时间和故障时间对应用程序的影响，以及要故障转移到首选可用性区域，这些功能将十分有用。
强制故障转移
你可以使用此功能在运行生产工作负载期间模拟计划外中断方案，并观察应用程序故障时间。 或者，在极少数情况下，如果主服务器因任何原因而变得无响应，则可以使用此功能。
此功能会导致主服务器停止运行，并启动可在其中执行备用服务器升级操作的故障转移工作流。 完成恢复过程并最终提交数据后，备用服务器将升级为主服务器。 DNS 记录将会更新，且应用程序可以连接到升级后的主服务器。 在后台建立新的备用服务器时，应用程序可以继续写入主服务器，而不会对运行时间产生影响。
下面是强制故障转移期间进行的步骤：
| 步骤 | 说明 | 是否出现应用停机？ |
|---|---|---|
| 1 | 在收到故障转移请求后，主服务器会立即停止。 | 是 |
| 2 | 主服务器关闭时，应用程序出现停机。 | 是 |
| 3 | 内部监视系统检测到故障，并启动到备用服务器的故障转移。 | 是 |
| 4 | 备用服务器在完全升级为独立服务器之前进入恢复模式。 | 是 |
| 5 | 故障转移过程会等待备用恢复完成。 | 是 |
| 6 | 服务器启动后，将以相同主机名更新 DNS 记录，但会使用备用服务器的 IP 地址。 | 是 |
| 7 | 应用程序可以重新连接到新的主服务器并恢复操作。 | 否 |
| 8 | 在首选区域中建立备用服务器。 | 否 |
| 9 | 备用服务器开始（从 Azure BLOB）恢复在建立期间丢失的日志。 | 否 |
| 10 | 在主服务器和备用服务器之间建立稳定状态。 | 否 |
| 11 | 强制故障转移过程已完成。 | 否 |
应用程序预计在步骤 1 后出现停机，并一直持续到步骤 6 完成。 其余步骤在后台进行，但不会影响应用程序写入和提交。
重要
端到端故障转移过程包括 (a) 在主服务器发生故障后故障转移到备用服务器，以及 (b) 在稳定状态下建立新的备用服务器。 由于应用程序仅在故障转移到备用服务器完成之前才会出现停机，因此请从应用程序/客户端（而非整个端到端故障转移过程）的角度来度量停机时间。
计划的故障转移
可以使用此功能以更短的故障时间进行到备用服务器的故障转移。 例如，在计划外故障转移后，主服务器可能位于与应用程序不同的可用性区域，于是你想让主服务器返回上一区域，与应用程序共置在一起。
执行此功能时，备用服务器首先需要确保可与最近的事务保持同步，以便应用程序能够继续执行读取/写入操作。 然后备用服务器会升级，并与主服务器的连接将断开。 在后台建立新的备用服务器时，应用程序可以继续写入主服务器。 下面是执行计划内故障转移涉及的步骤。
| 步骤 | 说明 | 是否出现应用停机？ |
|---|---|---|
| 1 | 等待备用服务器与主服务器同步。 | 否 |
| 2 | 内部监视系统启动故障转移工作流。 | 否 |
| 3 | 当备用服务器接近主日志序列号 (LSN) 时，应用程序写入操作会被拦截。 | 是 |
| 4 | 备用服务器升级为独立服务器。 | 是 |
| 5 | 以新备用服务器的 IP 地址更新 DNS 记录。 | 是 |
| 6 | 应用程序重新连接新的主服务器并恢复其读取/写入 | 否 |
| 7 | 在另一区域建立了新的备用服务器。 | 否 |
| 8 | 备用服务器开始（从 Azure BLOB）恢复在建立期间丢失的日志。 | 否 |
| 9 | 在主服务器和备用服务器之间建立稳定状态。 | 否 |
| 10 | 计划内故障转移过程已完成。 | 否 |
应用程序从步骤 3 开始停机，并在步骤 5 后恢复操作。 其余步骤在后台进行，但不会影响应用程序写入和提交。
执行按需故障转移期间要考虑的注意事项
- 整个端到端操作时间可能比应用程序出现的实际故障时间长。 请从应用程序的角度观察故障时间。
- 请不要一个紧接一个地执行故障转移。 在两次故障转移之间等待至少 15-20 分钟，这样有助于充分构建新备用服务器。
- 建议在活动较少期间执行故障时间较短的计划内故障转移。
请参阅本指南，了解管理高可用性的信息。
HA 服务器的时间点还原
配置为具有高可用性的灵活服务器会将日志数据实时复制到备用服务器。 主服务器上的任何用户错误（例如意外删除表或不正确的数据更新）也将复制到备用副本。 因此，不能使用备用副本恢复此类逻辑错误。 若要从这类错误中恢复，必须从备份执行时间点还原。 使用灵活服务器的时间点还原功能，你可以还原到错误发生前的时间点。 对于配置为高可用性的数据库，将使用用户提供的新服务器名称将新的数据库服务器还原为单一区域灵活服务器。 可以在少数情况下使用还原的服务器：
- 可以将还原的服务器用于生产用途，并可以选择启用区域冗余的高可用性。
- 如果只想还原某个对象，则可以从还原的数据库服务器导出该对象，然后将其导入生产数据库服务器。
- 如果想要克隆数据库服务器以便进行测试和开发，或者出于任何其他目的想要进行还原，则可以执行时间点还原。
高可用性 - 功能
备用副本将部署在与主服务器完全相同的 VM 配置（包括 vCore、存储空间、网络设置 (VNET、防火墙)等）中。
可以为现有数据库服务器添加高可用性。
可以通过禁用高可用性来删除备用副本。
对于区域冗余高可用性，可以为主数据库服务器和备用数据库服务器选择可用性区域。
停止、启动和重启等操作可在主数据库服务器和备用数据库服务器上同时执行。
自动备份从主数据库服务器执行并存储在区域冗余备份存储中。
客户端始终连接到主数据库服务器的最终主机名。
对服务器参数做出的任何更改也会应用于备用副本。
能够重新启动服务器以获取任何静态服务器参数更改。
定期维护活动（例如次要版本升级）首先在备用副本上进行，随后服务将进行故障转移以缩短停机时间。
高可用性 - 限制
可突发的计算层不支持高可用性。
只有在有多个区域可用的区域中才支持高可用性。
由于同步复制到备用服务器，尤其是使用区域冗余高可用性，因此应用程序可能会遇到更高的写入和提交延迟。
备用副本不能用于读取查询。
根据主服务器上的工作负载和活动，故障转移过程可能需要超过 120 秒的时间，这是因为备用副本需要恢复才能升级。
备用服务器通常以 40 MB/秒的速率恢复 WAL 文件。 如果工作负载超过此限制，则在故障转移期间或建立新的备用数据库后，可能需要较长时间才能完成恢复。
重启主数据库服务器也会重启备用副本。
不支持配置其他备用数据库。
配置客户启动的管理任务无法在托管维护时段进行计划。
计划事件（如缩放计算和缩放存储）先在备用服务器中进行，然后在主服务器中进行。 对于这些计划内操作，服务器目前不会进行故障转移。
如果使用已配置 HA 的灵活服务器配置逻辑解码或逻辑复制，那么当故障转移到备用服务器时，逻辑复制槽不会复制到备用服务器。
非 HA 服务器的可用性
对于未配置高可用性的灵活服务器，该服务仍提供内置可用性、存储冗余和复原能力，这有助于从任何计划内或计划外停机事件恢复。 此非 HA 配置中提供 99.9% 的 SLA 运行时间。
在计划内或计划外的故障转移事件期间，如果服务器发生故障，该服务将使用以下自动化过程来维持服务器的高可用性：
- 预配新的计算 Linux VM。
- 具有数据文件的存储映射到新的虚拟机
- PostgreSQL 数据库引擎在新的虚拟机上联机。
下图显示了 VM 和存储故障的过渡。
计划内故障时间
下面是一些计划内维护方案：
| 方案 | 说明 |
|---|---|
| 计算纵向扩展/缩减 | 当用户执行计算纵向扩展/缩减操作时，将使用缩放的计算配置来预配新的数据库服务器。 在旧的数据库服务器中，将允许处于活动状态的检查点完成，客户端连接将排空，所有未提交的事务将取消，然后将关闭该服务器。 然后会从旧数据库服务器分离存储并将其附加到新的数据库服务器。 它将启动并运行以接受任何连接。 |
| 纵向扩展存储 | 纵向扩展存储目前是一项脱机操作，涉及短暂的停机时间。 |
| 新软件部署 (Azure) | 在服务的计划内维护过程中，将自动推出新功能或修复 bug。 有关详细信息，请参阅文档并检查你的门户。 |
| 次要版本升级 | Azure Database for PostgreSQL 会自动将数据库服务器修补到 Azure 确定的次要版本。 这是在服务的计划内维护过程中发生的。 这会导致短暂的停机（以秒为单位），并且会自动重启装有新次要版本的数据库服务器。 有关详细信息，请参阅文档并检查你的门户。 |
计划外停机
意外的故障（包括基础硬件故障、网络问题和软件 bug）可能会导致计划外停机。 如果数据库服务器意外关闭，则会在数秒内自动预配一个新的数据库服务器。 远程存储会自动附加到新的数据库服务器。 PostgreSQL 引擎使用 WAL 和数据库文件执行恢复操作，并打开数据库服务器以允许客户端进行连接。 未提交的事务将丢失，并且必须由应用程序重试。 虽然计划外故障无法避免，但灵活服务器可以通过在数据库服务器和存储层上自动执行恢复操作来减少故障时间，无需人工干预。
下面介绍了一些故障场景以及灵活服务器如何自动恢复：
| 方案 | 自动恢复 |
|---|---|
| 数据库服务器故障 | 如果数据库服务器由于某些基础硬件故障而关闭，则会丢弃处于活动状态的连接，并中止任何正在进行的事务。 将自动部署新的数据库服务器，并将远程数据存储附加到新的数据库服务器。 在数据库恢复完成后，客户端可以使用同一终结点连接到新的数据库服务器。 恢复时间 (RTO) 取决于各种因素，包括发生故障时的活动，例如，在数据库服务器启动过程中需执行的大型事务和恢复量。 所构建的使用 PostgreSQL 数据库的应用程序需要能够检测并重试丢弃的连接和失败的事务。 |
| 存储故障 | 对于任何与存储相关的问题（例如磁盘故障或物理块损坏），应用程序看不到任何影响。 由于数据存储在 3 个副本中，因此将由未发生故障的存储提供数据的副本。 块损坏会自动修复。 如果丢失了数据的副本，则会自动创建数据的新副本。 |
下面是需要用户执行操作来进行恢复的一些故障场景：
| 方案 | 恢复计划 |
|---|---|
| 可用性区域故障 | 如果区域支持多个可用性区域，则备份会自动存储在区域冗余备份存储中。 如果发生区域故障，你可以从备份还原到另一个可用性区域。 这提供了区域级复原能力。 但是，这会产生还原和恢复时间。 由于并非所有 WAL 记录都已复制到备份存储，可能会丢失一些数据。 如果希望停机时间短而运行时间长，建议为服务器配置区域冗余高可用性。 |
| 逻辑/用户错误 | 在发生用户错误（例如，意外删除了表或错误地更新了数据）后进行的恢复涉及到执行时间点恢复 (PITR)，方法是将数据还原并恢复到发生错误之前的那个时间点。 如果只需还原部分数据库或特定的表，而不是还原数据库服务器中的所有数据库，则可在新实例中还原数据库服务器，通过 pg_dump 导出表，然后使用 pg_restore 将这些表还原到数据库中。 |
常见问题
HA 配置问题
在哪里可以看到灵活服务器提供的 SLA？
Azure Database for PostgreSQL SLA。是否需要配置 HA 来保护服务器免受计划外中断的影响？
不能。 灵活服务器提供有 3 个数据副本的本地冗余存储、区域冗余备份（在支持的区域）以及可自动重启故障服务器的内置服务器复原能力，甚至将服务器搬迁到另一个物理节点。 区域冗余 HA 通过执行自动故障转移到另一区域中另一台运行中（备用）服务器来提供更长的运行时间，从而提供具有区域复原能力的高可用性，且不会丢失数据。是否可以为主服务器和备用服务器选择可用性区域？
如果选择相同区域 HA，则只能选择主服务器。 如果选择区域冗余 HA，则可以选择主 AZ 和备用 AZ。区域冗余 HA 是否在所有区域中可用？
区域冗余 HA 适用于区域内支持多个 AZ 的区域。 有关最新区域支持，请参阅本文档。 我们会继续添加更多的区域并启用多个 AZ。 相同区域 HA 在所有支持区域中均可用。是否可以同时部署区域冗余 HA 和相同区域 HA？
否。 只能部署其中一个选项。是否可以将相同区域 HA 直接转换为区域冗余 HA，反之亦然？
否。 首先必须禁用 HA，等待它完成，然后再选择其他 HA 部署模型。主服务器和备用服务器之间的复制模式是什么？
主服务器和备用服务器之间会建立复制的同步模式。 只有在预写日志 (WAL) 数据保留在备用站点上之后，才会确认应用程序写入和提交。 这样，在发生故障转移时就不会丢失任何数据。同步模式导致延迟。 我的应用程序性能会受到哪些影响？
在 HA 中进行配置会导致写入和提交出现一些延迟。 读取查询不会受到影响。 对性能的影响因工作负载而异。 一般准则是，写入和提交可能会受到大约 20-30% 的影响。区域冗余 HA 是否会针对计划内中断和计划外中断提供保护？
是。 HA 的主要目的是提供更长的正常运行时间来减少中断带来的影响。 如果发生计划外中断（包括在数据库、VM、物理节点、数据中心中或在 AZ 级别出现错误），监视系统就会自动将服务器故障转移到备用服务器。 同样，在计划内中断（包括在计划的维护时段内发生的次要版本更新或基础结构修补）期间，更新会先应用于备用服务器，并且服务会在旧的主要服务器完成更新过程的同时进行故障转移。 这样就会缩短总体停机时间。是否可以随时启用或禁用 HA？
是。 你可以随时启用或禁用区域冗余 HA，但当服务器处于某些状态（如已停止、正在重启或已在故障转移过程中）时除外。
是否可以为备用服务器选择 AZ？
不是。 目前不能为备用服务器选择 AZ。 我们计划在将来添加该功能。是否可以在专用 (VNET) 和公共访问之间配置 HA？
不是。 可以在 VNET（在某个区域内跨 AZ）内或公共访问中配置 HA。是否可以跨区域配置 HA？
不是。 HA 在一个区域内进行配置，但跨越不同的可用性区域。 但是，可以在异步模式下启用异地只读副本，以实现异地复原。是否可以将逻辑复制与已配置 HA 的服务器配合使用？
可以配合 HA 配置逻辑复制。 但是，在故障转移后，逻辑槽详细信息不会复制到备用服务器上。 因此，目前对于这种配置方式的支持是有限的。 如果必须使用逻辑复制，则需要在每次故障转移后重新创建它。
与复制和故障转移相关的问题
灵活服务器在遇到错误（如 AZ 错误）时如何提供高可用性？
为服务器启用区域冗余 HA 时，与主要副本具有相同计算和存储配置的物理备用副本会自动部署到与主要副本不同的可用性区域中。 主服务器和备用服务器之间会建立 PostgreSQL 流式复制。在中断期间，典型的故障转移过程是怎样的？
在监视系统检测到故障时，它将启动故障转移工作流，其中包括确保备用服务器已应用了所有残留的 WAL 文件，并且已在打开这些文件以进行读/写操作之前完全更新。 然后，DNS 会更新为备用服务器的 IP 地址，之后客户端就可以重新连接到具有相同终结点（主机名）的服务器。 新的备用服务器会进行实例化，使配置始终处于高度可用模式。在中断期间，典型的故障转移时长和预期的数据丢失是多少？
在典型情况下，从应用程序的角度而言，故障转移时间或故障时间介于 60 秒至 120 秒之间。 如果在长期事务、索引创建或大量写入活动的过程中发生中断，这个时间可能会更长，因为备用服务器需要更长时间才能完成恢复过程。由于复制是在同步模式下发生，因此不会有数据丢失。
是否会为故障转移时间提供 SLA？
对于故障转移时间，我们会提供关于该操作通常需要多久的准则。 我们会为总体运行时间提供正式的 SLA。在故障转移后，应用程序是否会自动连接到服务器？
不是。 应用程序应具有重试机制，以便重新连接到同一终结点（主机名）。如何测试故障转移？
可以使用“强制故障转移”或“计划内故障转移”功能来测试故障转移。 有关详细信息，请参阅本文档中的“按需故障转移”部分。如何检查复制状态？
在门户上，服务器的“概述”页会显示区域冗余高可用性状态和服务器状态。 还可以从服务器门户的“高可用性”边栏选项卡检查主要服务器与备用服务器的状态和 AZ。可以从 psql 中运行
select * from pg_stat_replication;，这样会显示流式传输状态等详细信息。备用副本上是否支持读取查询？
不是。 我们不支持在备用副本上读取查询。在执行时间点还原 (PITR) 时，该操作是否会在 HA 中自动配置已还原的服务器？
不是。 PITR 服务器会还原为独立的服务器。 如果要启用 HA，可以在还原完成后执行此操作。