PostgreSQL 中 Azure 数据库的可靠性

Azure Database for PostgreSQL是一种完全托管的数据库服务，可提供对数据库管理功能和配置设置的精细控制和灵活性。 该服务根据要求提供高可用性和灾难恢复功能。

使用 Azure 时，可靠性是共同的责任。 Azure提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍如何使Azure Database for PostgreSQL应对各种潜在中断和问题，包括暂时性故障、可用性区域中断、区域中断和服务维护。 它还介绍了如何使用备份从其他类型的问题中恢复，并突出显示有关Azure Database for PostgreSQL服务级别协议（SLA）的关键信息。

生产部署建议

若要了解如何部署Azure Database for PostgreSQL以支持解决方案的可靠性要求，以及可靠性如何影响体系结构的其他方面，请参阅 Azure Well-Architected Framework 中有关Azure Database for PostgreSQL的体系结构最佳做法。

可靠性体系结构概述

本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。

逻辑体系结构

使用 Azure Database for PostgreSQL时，部署一个服务器，该服务器表示支持部署到服务器的数据库所需的计算和存储资源。

您可以在多个 计算层级 中部署服务器：突发型、通用型和内存优化型。 每个层 针对不同类型的工作负荷进行优化。

有关常规服务体系结构和部署模型的详细信息，请参阅Azure Database for PostgreSQL概述。

物理体系结构

• Compute 和存储分离： Azure Database for PostgreSQL使用计算和存储分离体系结构来支持高可用性。 数据库引擎在 Linux 虚拟机（VM）上运行，而Azure 存储保存数据文件，并保留数据库文件的三个本地冗余同步副本，以确保数据持久性。

• 高可用性： 可以在服务器上启用高可用性配置。 启用高可用性配置时，服务会预配和维护暖备用服务器。 主服务器同步将数据更改复制到备用服务器，以确保主服务器发生故障期间不会丢失任何数据。

  该体系结构将计算层与存储层分开，因此服务可以适当地处理不同类型的故障。 为了提高复原能力，可以将服务器分散到可用性区域。

  

  展示 Azure Database for PostgreSQL 高可用性体系结构的示意图。 两个服务器并排。 左侧是一个标记为主服务器的框，在该框中是虚拟机和磁盘。 右侧是一个标有备用服务器的匹配框，该服务器还包含虚拟机和磁盘。 水平箭头从左侧的主服务器指向右侧的备用服务器，箭头标记为流复制，指示数据从主服务器流式传输到备用服务器的单向关系。

  备用服务器部署在与主服务器相同的 VM 配置中，包括 vCore、存储和网络设置。

  可以通过执行 故障转移在服务器之间切换。 存在两种类型的 故障转移：强制故障转移，在主服务器发生故障时使用，以及 计划内故障转移，这些故障转移在一些维护操作期间使用，在其他情况下，需要在故障转移期间最大程度地减少应用程序停机时间。

  执行停止、启动和重启等操作时，它们同时发生在主数据库服务器和备用数据库服务器上。 计划的事件（例如计算缩放和存储缩放）首先在备用服务器上，然后在主服务器上发生。 当前，服务器不会在这些计划的操作中进行故障转移。

  有关详细信息，请参阅 Azure Database for PostgreSQL 中的高可用性。

• Backups： Azure Database for PostgreSQL会自动创建服务器备份。 有关详细信息，请参阅 备份和还原。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。

应用程序必须处理在维护、缩放操作或网络中断期间可能发生的暂时性连接错误。 遵循以下建议：

有关详细信息，请参阅 Azure Database for PostgreSQL 中处理暂时性连接错误。

应对可用区故障的弹性

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

通过高可用性配置选择可用性区域支持类型。 启用高可用性时，该服务会将备用服务器与主服务器一起部署。 此高可用性模型有助于确保提交的数据在失败期间永远不会丢失。 无论服务器使用哪种高可用性部署模型，它都同步将数据提交到主服务器和备用服务器。 如果主服务器出现故障，服务器会自动转移到备用服务器。

每个可用区都会将数据文件和预写日志（WAL）存储在采用本地冗余存储（LRS）的高级托管磁盘上，LRS 会在每个可用区内自动保存三个数据副本。

使用高可用性时，Azure Database for PostgreSQL支持两种可用性区域配置类型：

• 区域冗余高可用性： 区域冗余通过在一个可用性区域中部署主服务器和位于不同可用性区域中的备用服务器来提供最高级别的区域复原能力。 备用服务器使用与主服务器类似的计算、存储和网络配置。 区域冗余配置会在主服务器和备用服务器之间为整个堆栈提供物理隔离。

  可以选择主服务器和备用服务器的可用性区域，或者让Azure选择它们。

  建议为生产服务器部署区域冗余部署。

  

  展示跨可用区部署的 Azure Database for PostgreSQL 区域冗余配置的示意图。 顶部列出了三个区域：可用性区域 1、可用性区域 2 和可用性区域 3。 在可用性区域 1 下，一个标记为主服务器的框，在该框中是虚拟机和磁盘，显示主服务器由计算和存储组成。 在可用性区域 2 下，有一个标记为备用服务器的匹配框，该服务器还包含虚拟机和磁盘。 在这两个服务器框之间，有一个标注为“流复制”的向右箭头，表明数据更改从左侧的主服务器流向右侧的备用服务器。 布局传达跨区域复原能力：主区域和备用区域在两个可用性区域之间分隔，而可用性区域 3 仍然未使用。

  写入操作在提交延迟方面可能会略有增加，因为服务会同步将数据复制到备用服务器。 影响因工作负荷、所选 SKU 和区域而异。

• 区域（同区域）高可用性： 主服务器和备用服务器使用相同的可用性区域。 如果主服务器发生中断，而区域仍然健康，则服务器会自动切换到备用服务器。 区域部署提供单个可用性区域中的高可用性。 它可以保护你免受节点级故障的影响，还有助于在计划内和计划外停机事件期间减少应用程序停机时间。 但是，它不会防止该区域出现中断。

  

  显示单个可用性区域中 Azure Database for PostgreSQL 区域部署配置的示意图。 显示了三个区域：可用性区域 1、可用性区域 2 和可用性区域 3。 在可用区 1 中，有两个方框并排放置。 左侧的框标记为主服务器，在该框中是虚拟机和磁盘。 右侧的框标记为备用服务器，在该框中是虚拟机和磁盘。 在这两个服务器框之间，有一个标注为“流复制”的向右箭头，表明数据更改从左侧的主服务器流向右侧的备用服务器。 这两个服务器位于同一可用性区域中。 可用性区域 2 和可用性区域 3 未使用。

  区域性（同区域）高可用性仅在以下情况下可用：

  • 该区域不支持可用性区域。 区域实际上充当单个区域，因此可以选择的唯一高可用性配置是同一区域。
  • 如果某个区域没有足够的容量进行区域冗余部署，服务最初可以将这两个服务器置于同一可用性区域中，然后在容量可用时自动将其迁移到单独的区域。 使用 Azure 门户或Azure CLI部署服务器时，可以使用此选项。 有关详细信息，请参阅 “配置业务关键”（高可用性）选项。

  将服务器放置在同一区域中可以减少对在同一区域中部署的应用程序的写入延迟。

  当服务器位于同一区域时，可以减少对在同一区域中部署的应用程序的写入延迟。

如果在没有高可用性的情况下配置服务器，则会在单个服务器上运行。 如果该服务器或其区域出现故障，则服务器不可用。 有关详细信息，请参阅 没有可用性区域的配置。

要求

• 区域支持：Azure Database for PostgreSQL支持跨Azure区域的不同可用性区域配置。 有关区域的完整列表以及可用性区域支持类型以及每个区域的任何特定注意事项，请参阅Azure区域。

• 计算层： 下表列出了每种可用性区域支持的计算层支持：

  计算层级	区域冗余	区域型（相同区域型）
  可突发	不支持	不支持
  常规用途	支持	支持
  内存优化	支持	支持

• 服务层级： 这两种类型的高可用性都需要“常规用途”或“内存优化”层。

注意事项

区域容量： 如果某个区域没有足够的容量用于区域冗余部署，服务最初可以将这两个服务器置于同一可用性区域中，并在容量可用时自动将其迁移到单独的区域。 使用 Azure 门户或Azure CLI部署服务器时，可以使用此选项。 有关详细信息，请参阅 “配置业务关键”（高可用性）选项。

Cost

启用高可用性时，将创建备用服务器，并按与主服务器相同的费率计费。 可用性区域配置不会影响成本。 可用性区域中或可用性区域之间的数据复制不收取任何费用。 根据备份存储容量，您可能还会被收取备份存储费用。 有关详细的定价信息，请参阅 Azure Database for PostgreSQL 定价。

配置可用性区域支持

若要配置服务器的可用性区域支持，请配置高可用性设置。

• 创建区域冗余服务器：若要了解如何创建启用了高可用性和区域冗余的服务器，请参阅快速入门：创建Azure Database for PostgreSQL服务器。

• 更改现有服务器的可用性区域配置： 通过更改高可用性设置来更改现有服务器的可用性区域配置。 有关详细步骤，请参阅 为现有服务器启用高可用性。

  不能更改用于主服务器或备用服务器的区域。 需要再次创建服务器。

  小窍门

  我们建议您在服务器活动负载较低时，再更改高可用性配置。

• 禁用高可用性： 禁用高可用性会移除备用服务器，因此您的服务器在其可用性区域中遇到中断时将不具备弹性。 有关详细信息，请参阅 “禁用高可用性”。

所有区域正常时的行为

本部分介绍配置具有高可用性和可用性区域支持的服务器时的预期情况，并且所有可用性区域都正常运行。

• 跨区域操作： PostgreSQL 客户端应用程序使用数据库服务器名称连接到主服务器。 Azure Database for PostgreSQL使用主动-被动配置，其中主可用性区域中的主服务器处理所有数据库连接和查询。 备用服务器在正常操作期间不提供客户端流量。

• 跨区域数据复制： 主服务器将更改同步复制到备用服务器。 在主服务器和备用服务器确认写入之前，事务不会被视为已完成。

  当应用程序写入和提交数据时，PostgreSQL 首先记录主服务器上的 WAL 中的更改。 主服务器使用 PostgreSQL 流式处理协议将这些日志流式传输到备用服务器。 在备用服务器持久存储 WAL 后，主服务器会确认写入。 应用程序仅在收到确认后提交其事务。 此确认过程不会等待日志应用于备用服务器。

  复制的影响因服务器使用的可用性区域配置而异：

  • 区域冗余： 由于服务器位于单独的区域中，因此此方法可确保在发生区域故障期间丢失零数据。 这种情况有时也称为实现针对区域故障的零恢复点目标（RPO）。

    但是，跨区域复制可能会带来少量的额外延迟。 延迟的影响取决于应用程序。 对于大多数应用程序，额外的延迟是微不足道的。

  • 区域：由于两个服务器位于同一区域，因此不会在区域之间复制任何流量。

  注释

  系统将日志数据实时复制到备用服务器。 主服务器上的任何用户错误（例如意外删除表或不正确的数据更新）都会复制到备用服务器。 无法使用备用服务器从这类错误中恢复，必须从备份执行时间点恢复。 有关详细信息，请参阅 备份和还原。

区域故障期间的行为

本节介绍将服务器配置为支持高可用性和可用区后，在某个可用区发生中断时您可以预期会出现什么情况。

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

  如果可用性区域失败，则行为会有所不同，具体取决于服务器使用的可用性区域配置：

  • Zone-redundant： Azure Database for PostgreSQL会自动检测可用性区域故障。 若要查看可能的高可用性状态类型，请参阅 高可用性（HA）运行状况监视。 当某个区域发生故障时，Azure启动强制故障转移备用服务器，而无需执行操作。

  • 区域： 如果托管区域服务器的可用区变得不可用，则主服务器和备用服务器都将不可用。 在此方案中，该服务不提供自动故障转移。 你负责检测区域中断和执行恢复操作，例如将区域冗余备份还原到另一个可用性区域或区域中的单独服务器。

• 通知：Azure Database for PostgreSQL中的高可用性运行状况监视持续概述了已启用高可用性的实例的运行状况和就绪情况。 监视功能基于 Azure 资源运行状况 构建，可以检测和警报可能影响数据库的故障转移准备情况或总体可用性的任何问题。 评估连接状态、故障转移状态和数据复制运行状况等关键指标，以实现主动故障排除并帮助维护数据库的运行时间和性能。

  有关配置和解读 HA 健康状态的详细指南，请参阅 高可用性（HA）健康状态监控。

• 活动请求： 当可用性区域变得不可用时，可能会终止对受影响区域中服务器的任何正在进行的请求。 应用程序必须重试这些请求。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。

• 预期数据丢失： 数据丢失量取决于服务器使用的可用性区域配置。

  • 区域冗余： 由于不同区域中的主服务器和备用服务器之间的同步复制，区域故障转移期间预计会出现零数据丢失。

  • 区域： 受影响区域中的服务器上的数据在区域恢复前不可用。

• 预期的停机时间： 停机时间量取决于服务器使用的可用性区域配置。

  • 区域冗余： 故障转移通常在 60-120 秒内完成。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。

  • 纬 向： 在可用性区域恢复之前，受影响区域中的服务器不可用。

• 分配： 流量重新路由行为取决于服务器使用的可用性区域配置。

  • 区域冗余： 故障转移后，以前的备用服务器将成为新的主服务器，并开始接受新连接。 Azure恢复后，会自动在原始主区域中建立新的备用服务器。 如需完整详情，请参阅 强制故障转移。

  • 区域性： 当某个区域不可用时，服务器也会不可用。 如果你在另一个可用性区域或区域中预先创建了单独的服务器，则负责将流量重新路由到该服务器。

区域恢复

区域恢复行为取决于服务器使用的可用性区域配置。

• 区域冗余：当可用性区域恢复时，Azure Database for PostgreSQL会自动重新生成恢复区域中的备用服务器，并将其与当前主服务器同步。 然后，恢复的区域充当备用位置。 为了避免不必要的中断，服务不会自动将主角色移回原始区域。 如果您希望将主数据库返回到原始区域，可以手动启动计划内故障转移。

• 区域：在区域恢复正常后，区域内的服务器将再次可用。 你负责工作负荷所需的任何区域恢复过程和数据同步。

测试区域故障

测试区域故障的选项取决于实例使用的可用性区域配置。

• 区域冗余： 您可以通过启动强制故障转移来测试应用程序的容错能力。 通过使用强制故障转移，您可以在工作负荷运行时模拟未计划的停机情况，并观察应用程序的停机时间。 建议在非生产环境中或在安静时间运行模拟。 有关详细信息，请参阅 启动强制故障转移。

• 可用区： 虽然您无法模拟整个可用区发生中断，但可以通过一种类似于可用区中断的方式来模拟服务器不可用。 有关详细信息，请参阅 停止服务器计算。

对区域范围的故障的复原能力

Azure Database for PostgreSQL支持 跨区域只读副本，可用于在不同的区域中维护数据库的同步副本，以加快恢复速度。

还可以在受支持的区域中使用异地冗余备份来提供跨区域恢复。 但是，备份通常涉及比复制更多的停机时间和数据丢失。 有关详细信息，请参阅 备份和还原。

跨区域只读副本

可以部署只读副本来保护数据库免受区域级故障的影响。 每个只读副本都是一个单独的 Azure Database for PostgreSQL 服务器。 将只读副本放置在第二个 Azure 区域中时，您的数据库服务器可以提供一个针对区域性问题的复原能力。 最多可以部署五个只读副本，这些副本可以选择位于不同的Azure区域中。 PostgreSQL 的物理复制技术以异步方式更新读副本，它们可能会滞后于主副本。 跨区域只读副本可以选择为只读工作负荷提供服务，以减少全局分布式应用程序的延迟或从主服务器卸载读取流量。 如需详细了解只读副本的功能和注意事项，请参阅只读副本。

虚拟终结点 提供读写终结点和只读终结点，并在提升副本时自动重定向流量，这有助于最大程度地减少故障转移事件期间的停机时间。 强烈建议将虚拟终结点与跨区域只读副本配合使用，以提高应用程序复原能力。 有关详细信息，请参阅 Azure Database for PostgreSQL 中只读副本的虚拟终结点。

如果您的主要区域出现故障，您可以触发提升，使次要副本成为主要副本。 根据使用只读副本的方式，不同类型的故障转移可能适用。 使用只读副本为地区故障提供弹性时，通常使用提升到主服务器的方法来更新虚拟端点。 在区域中断期间，需要执行 强制升级，这可能会导致任何未复制的数据丢失。 在主要区域正常运行的计划方案中，可以选择执行计划升级以避免数据丢失。 有关详细信息，请参阅 在 Azure Database for PostgreSQL 中提升只读副本。

要求

• 区域支持：可以在支持Azure Database for PostgreSQL的任何区域中创建跨区域只读副本。 你并不局限于 Azure 配对区域。

• 计算层： 常规用途和内存优化计算层支持只读副本。 该可突发层不支持只读副本。

注意事项

• 配置差异： 只读副本可能不会从主服务器继承所有配置设置。 计划在故障转移后配置必要的设置。 主服务器和副本应该是 对称的，这意味着它们需要对某些设置具有相同的层、存储大小和值。 在区域故障期间，可以放弃对称服务器要求进行强制升级，但最好尽可能使用对称配置来避免意外问题。 有关详细信息，请参阅 配置管理。

• 监视复制滞后时间： 异步复制过程需要复制滞后时间，这可能因多种因素而异。 复制滞后时间较高时，服务器可能会遇到问题。 请务必监视复制延迟，以便在问题恶化之前缓解问题。 有关详细信息，请参阅 “监视复制”。

• 高可用性： 只读副本无法启用高可用性，在升级副本时，它们也没有高可用性。 升级副本后，你负责配置高可用性。

有关要考虑的促销流程的其他因素，请参阅 “注意事项”。

Cost

只读副本会产生计算和存储费用，此外还会产生因复制而产生的跨区域数据传输费用。 有关详细的定价信息，请参阅 Azure Database for PostgreSQL 定价和 Bandwidth 定价。

配置多区域支持

• 创建只读副本： 若要了解如何创建只读副本，请参阅 “创建只读副本”。 创建主服务器后，可以配置副本，前提是主服务器正在运行且可访问。

  若要创建虚拟终结点，请参阅 “创建虚拟终结点”。

• 删除只读副本： 若要了解如何删除只读副本，请参阅 “删除只读副本”。

当所有区域都正常时的行为

本部分介绍在使用另一个区域和虚拟终结点中的只读副本配置服务器时会发生什么情况，并且所有区域都正常运行：

• 区域之间的流量路由： 在正常操作中，虚拟终结点将读写终结点的流量定向到主要区域中的主服务器。 如果还使用虚拟终结点的只读终结点，则会将流量定向到所配置的副本。

• 区域之间的数据复制： 跨区域只读副本使用异步复制来最大程度地减少对主服务器性能的影响。 复制滞后时间取决于许多因素，包括写入负载和主服务器和副本之间的延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。

区域故障期间的行为

本节介绍当服务器配置了另一个区域中的只读副本和虚拟终结点，而主要区域发生故障时，会发生什么情况：

• 检测和响应： 你需要负责检测主要区域的中断，并手动将只读副本提升为新的主服务器。 在区域中断期间，必须执行强制升级，这会导致任何未复制的数据丢失。

  重要

  你负责触发促销。 即使出现区域故障，Azure也不会自动升级只读副本。

  有关启动升级的详细步骤，请参阅 将只读副本切换到主副本。

• Notification： Azure不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报通知问题。

• 活动请求： 升级过程会删除与主要区域的所有活动连接。 升级过程完成后，应用程序需要重试建立与升级副本的连接。

• 预期数据丢失： 在区域中断期间，必须执行强制升级，这会导致任何未复制的数据永久丢失。

  数据丢失量取决于服务中断时的复制延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。

• 预期的停机时间： 强制升级通常在触发后的 1-3 分钟内完成。 应用程序可能还需要重新连接到正确的终结点。 虚拟终结点作为强制升级过程的一部分进行更新。 应用程序应遵循终结点 DNS 记录的生存时间（TTL），以确保在升级完成后快速重新连接到正确的副本。

• 流量重新路由： 服务器的虚拟终结点会自动将应用程序流量重定向到新的主副本。

  注释

  将只读副本提升为主服务器后，它未启用高可用性配置。 需要手动启用高可用性配置，或将其添加到自己的自动化进程。

区域恢复

使用虚拟终结点时，主要区域恢复后，旧的主服务器会自动配置为只读副本。 可以执行另一个提升操作，将主操作返回到您首选的主要区域。

针对区域故障进行测试

定期测试只读副本升级过程，以确保你的进程有效，并且这些功能满足恢复时间目标（RTO）和恢复点目标（RPO）要求。

即使所有区域状态正常，也可以随时将只读副本提升为主服务器。 用于测试：

• 可以执行强制升级测试。 建议在非生产环境中执行这些测试，因为它可能会导致数据丢失。 强制升级测试有助于模拟在区域中断期间看到的行为。
• 对于计划内维护或想要避免数据丢失的测试方案，请改用计划的升级。 但是，计划升级遵循与区域中断期间升级不同的过程，因此在真正的区域中断期间，它可能不会反映行为。

有关分步说明，请参阅 将只读副本切换到主副本。

作为灾难恢复策略的一部分，请定期运行完整的恢复演练。 这些演练应包括数据验证、应用程序功能测试和记录的回滚过程。

备份和还原

Azure Database for PostgreSQL自动备份数据。 这些备份提供时间点恢复功能，有助于防止意外损坏和删除数据。 Azure完全管理备份。 它们不会中断服务器的可用性，并且包括完整备份和事务日志备份。

• 备份存储： 如果在具有可用性区域的区域中部署服务器，服务会将备份存储在区域冗余存储（ZRS）中，而不考虑服务器的高可用性配置。 对于在没有可用性区域的区域中部署的服务器，服务会将备份存储在本地冗余存储（LRS） 中。

  在具有对的Azure区域中，可以在服务器创建时配置异地冗余备份存储，以便将备份复制到Azure配对区域，以防止区域故障。 服务异步复制备份。

  默认备份保留期为 7 天，但可将保留期延长至 35 天。 还可以将Azure 备份用于长达 10 年的手动备份的长期存储。 所有备份均已加密。

• 恢复： 时间点恢复允许将数据库还原到备份保留期内的任何时刻。 还原过程使用新的用户提供的服务器名称创建新的数据库服务器。 可以使用新服务器 as-is 或从中复制数据。

  还原异地冗余备份时，将在配对区域中创建新的服务器。

  此功能可用于从意外的数据修改、应用程序错误或测试方案中恢复。

对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。

有关详细信息，请参阅 Azure Database for PostgreSQL 的备份和还原。

服务维护期间的系统弹性能力

Azure Database for PostgreSQL自动处理关键服务任务，包括修补基础硬件、操作系统和数据库引擎。 该服务包括安全更新、软件更新和次要版本升级，作为计划内维护的一部分。

若要确保服务器在维护时段内保持可用状态，请遵循以下建议：

服务级别协议

Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。

Azure Database for PostgreSQL提供不同的可用性 SLA，具体取决于服务器的配置：

• 配置有区域冗余高可用性的服务器提供的运行时间承诺 SLA 为 99.99%。
• 配置有区域性高可用性的服务器提供运行时间 SLA 99.95%。
• 未配置高可用性的服务器提供 99.9% 的运行时间服务水平协议 (SLA)。

相关内容

• Azure可靠性
• Azure Database for PostgreSQL 的架构最佳实践
• Azure Database for PostgreSQL 的业务连续性概述
• Azure Database for PostgreSQL 中的地理灾难恢复
• 实现复原和可恢复性原则的 Terraform 脚本