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