你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for PostgreSQL 是一项完全托管的数据库服务，旨在提供对数据库管理功能和配置设置的精细控制和灵活性。 该服务根据要求提供高可用性和灾难恢复功能。
使用 Azure 时，可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍如何使 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 区域中，可以使用 Azure 机密计算部署服务器。
有关常规服务体系结构和部署模型的详细信息，请参阅 什么是 Azure Database for PostgreSQL？。
物理体系结构
计算和存储分离： Azure Database for PostgreSQL 使用计算和存储分离体系结构来支持高可用性。 数据库引擎在 Linux 虚拟机上运行，而数据文件存储在 Azure 存储中，该存储维护数据库文件的三个本地冗余同步副本，以确保数据持久性。
高可用性： 可以选择在服务器上启用 高可用性配置 。 启用高可用性配置时，服务会预配和维护暖备用服务器。 主服务器上的数据更改同步复制到备用服务器，以确保主服务器发生故障期间不会丢失任何数据。
该体系结构将计算层与存储层分开，使服务能够适当地处理不同类型的故障。 为了提高复原能力，可以将服务器分散到可用性区域。
备用服务器部署在与主服务器相同的 VM 配置中，包括 vCore、存储和网络设置。
可以通过执行 故障转移在服务器之间切换。 有两种类型的 故障转移：强制故障转移，在主服务器发生故障时使用，以及计划内故障转移，这些 故障转移在一些维护操作期间使用，在其他情况下，需要在故障转移期间最大程度地减少应用程序停机时间。
停止、启动和重启等操作可在主数据库服务器和备用数据库服务器上同时执行。 计划的事件（例如，缩放计算和缩放存储）首先在备用服务器上发生，然后在主服务器上发生。 当前，服务器不会在这些计划的操作中进行故障转移。
有关详细信息，请参阅 Azure Database for PostgreSQL 中的高可用性。
备份： Azure Database for PostgreSQL 会自动创建服务器备份。 有关详细信息，请参阅 备份和还原。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。
应用程序必须处理在维护、缩放操作或网络中断期间可能发生的暂时性连接错误。 遵循以下建议：
- 当应用程序遇到暂时性故障时，请使用指数退避重试操作。 增加重试之间的延迟并限制尝试次数。 如果操作在最大重试后仍然失败，则将其视为失败。
- 尽可能使用自动处理重试的客户端库（也称为驱动程序）。
- 在写入操作期间发生的暂时性错误需要仔细考虑。 请考虑使写入操作成为幂等的，以确保能够安全地多次执行。
有关详细信息，请参阅 在 Azure Database for PostgreSQL 中处理暂时性连接错误。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上独立的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
可以通过 高可用性 配置选择可用性区域支持的类型。 启用高可用性会将 备用 服务器与主服务器一起部署。 此高可用性模型有助于确保提交的数据在失败期间永远不会丢失。 无论服务器使用哪种高可用性部署模型，数据都同步提交到主服务器和备用服务器。 如果主服务器出现故障，服务器会自动转移到备用服务器。
数据文件和预写日志（WAL）存储在每个可用性区域中的高级托管磁盘上，本地冗余存储（LRS）会自动在每个区域中存储三个数据副本。
使用高可用性时，Azure Database for PostgreSQL 支持两种可用性区域配置类型：
区域冗余高可用性： 区域冗余通过在一个可用性区域中部署主服务器和位于不同可用性区域中的备用服务器来提供最高级别的区域复原能力。 备用服务器使用与主服务器类似的计算、存储和网络配置。 区域冗余配置会在主服务器和备用服务器之间为整个堆栈提供物理隔离。
可以选择主服务器和备用服务器的可用性区域，或者让Microsoft选择它们。
建议为生产服务器部署区域冗余部署。
写入操作在提交延迟方面可能会略有增加，因为服务会同步将数据复制到备用服务器。 影响因工作负荷、所选 SKU 和区域而异。
区域（同区域）高可用性： 主服务器和备用服务器使用相同的可用性区域。 如果主服务器发生中断，而区域仍然健康，则服务器会自动切换到备用服务器。 区域部署提供单个可用性区域中的高可用性。 它可以保护你免受节点级故障的影响，还有助于在计划内和计划外停机事件期间减少应用程序停机时间。 但是，它不会防止该区域出现中断。
区域性（同区域）高可用性仅在以下情况下可用：
- 该区域不支持可用性区域。 区域实际上充当单个区域，因此可以选择的唯一高可用性配置是同一区域。
- 如果某个区域没有足够的容量用于区域冗余部署，服务最初可以将这两个服务器置于同一可用性区域中，并在容量可用时自动将其迁移到单独的区域。 使用 Azure 门户或 Azure CLI 部署服务器时，可以使用此选项。 有关详细信息，请参阅 “配置业务关键”（高可用性）选项。
由于服务器位于同一区域，因此可以减少对在同一区域中部署的应用程序的写入延迟。
如果在没有高可用性的情况下配置服务器，则会在单个服务器上运行。 如果该服务器或其区域出现故障，则服务器不可用。 有关详细信息，请参阅 没有可用性区域的配置。
要求
区域支持： Azure Database for PostgreSQL 对可用性区域配置的支持在 Azure 区域之间有所不同。 有关区域的完整列表以及可用性区域支持类型以及该区域的任何特定注意事项，请参阅 Azure 区域。
计算层： 下表列出了每种可用性区域支持的计算层支持：
定价等级 Zone-redundant 区域型（相同区域型） 可突发 不支持 支持 常规用途 支持 支持 内存优化 支持 支持 服务层级： 区域冗余需要常规用途或内存优化层。
所有定价层都支持区域（同区域）部署。
注意事项
区域容量： 如果某个区域没有足够的容量用于区域冗余部署，服务最初可以将这两个服务器置于同一可用性区域中，并在容量可用时自动将其迁移到单独的区域。 使用 Azure 门户或 Azure CLI 部署服务器时，可以使用此选项。 有关详细信息，请参阅 “配置业务关键”（高可用性）选项。
Cost
启用高可用性时，将创建备用服务器，并按与主服务器相同的费率计费。 可用性区域配置不会影响成本。 可用性区域中或可用性区域之间的数据复制不收取任何费用。 根据备份存储容量，您可能还会被收取备份存储费用。 有关详细的定价信息，请参阅 Azure Database for PostgreSQL 定价。
配置可用性区域支持
若要为服务器配置可用性区域支持，请配置高可用性设置。
创建区域冗余服务器： 若要了解如何创建启用了高可用性和区域冗余的服务器，请参阅 快速入门：在 Azure 门户中创建 Azure Database for PostgreSQL。
更改现有服务器的可用性区域配置： 可以通过更改高可用性设置来更改现有服务器的可用性区域配置。 有关详细步骤，请参阅 为现有服务器启用高可用性。
创建主服务器或备用服务器后，无法更改用于主服务器或备用服务器的区域。 需要重新创建服务器。
小窍门
建议在服务器活动较低的情况下，再更改高可用性配置。
禁用高可用性： 禁用高可用性会移除备用服务器，因此您的服务器在其可用性区域中遇到中断时将不具备弹性。 有关详细信息，请参阅 “禁用高可用性”。
所有区域正常时的行为
本部分介绍在服务器配置了高可用性和可用区支持且所有可用区均正常运行时的预期情况。
跨区域操作： PostgreSQL 客户端应用程序使用数据库服务器名称连接到主服务器。 Azure Database for PostgreSQL 使用主动/被动配置，其中所有数据库连接和查询均由主可用性区域中的主服务器处理。 备用服务器在正常操作期间不提供客户端流量。
跨区域数据复制： 对数据的更改在主服务器和备用服务器之间同步复制。 在主服务器和备用服务器确认写入之前，事务不会被视为已完成。
应用程序事务触发的写入首先将第一个日志写入主服务器上的 WAL，然后提交。 主服务器使用 Postgres 流式处理协议将这些日志流式传输到备用服务器。 当备用服务器存储保留日志时，主服务器会确认写入完成。 应用程序仅在收到确认后提交其事务。 此确认过程不会等待日志应用于备用服务器。
复制的影响因服务器使用的可用性区域配置而异：
区域冗余： 由于服务器位于单独的区域中，因此此方法可确保在发生区域故障期间丢失零数据。 这种情况有时也称为实现针对区域故障的零恢复点目标（RPO）。
但是，跨区域复制可能会带来少量的额外延迟。 延迟的影响取决于应用程序，对于大多数应用程序而言，它可忽略不计。
区域：由于两个服务器位于同一区域，因此不会在区域之间复制任何流量。
注释
系统将日志数据实时复制到备用服务器。 主服务器上的任何用户错误（例如意外删除表或不正确的数据更新）都会复制到备用服务器。 因此，您无法使用备用恢复这些类型的错误，必须从备份执行指定时间点还原。 有关详细信息，请参阅 备份和还原。
区域故障期间的行为
本部分介绍当服务器配置了高可用性和可用性区域支持，并且出现可用性区域中断时应期待的情况。
检测和响应： Azure 会定期检查主服务器和备用服务器的运行状况。 多次 ping 后，如果运行状况监视检测到主服务器无法访问，该服务将启动自动故障转移到备用服务器。 健康监测算法使用多个数据点来避免误报事件。
发生区域故障时，行为因服务器使用的可用性区域配置而异：
通知： Azure Database for PostgreSQL 中的高可用性（HA）运行状况监视持续概述了已启用 HA 的实例的运行状况和就绪情况。 监视功能基于 Azure 资源运行状况构建，可以检测和警报可能影响数据库的故障转移准备情况或总体可用性的任何问题。 评估连接状态、故障转移状态和数据复制运行状况等关键指标，以实现主动故障排除并帮助维护数据库的运行时间和性能。
有关配置和解释 HA 运行状况的详细指南，请参阅 Azure Database for PostgreSQL 的高可用性（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 配对区域。
计算层： 常规用途和内存优化计算层支持只读副本。 该可突发层不支持只读副本。
注意事项
配置差异： 只读副本可能不会从主服务器继承所有配置设置。 在故障转移完成后，计划进行必要的设置配置。 主服务器和副本应该是 对称的，这意味着它们需要对某些设置具有相同的层、存储大小和值。 在区域故障期间，可以放弃对称服务器要求进行强制升级，但最好尽可能使用对称配置来避免意外问题。 有关详细信息，请参阅 配置管理。
监视复制滞后时间： 异步复制过程需要复制滞后时间，具体取决于多种因素。 复制滞后时间非常高时，服务器可能会遇到问题。 请务必监视复制延迟，以便在问题恶化之前缓解问题。 有关详细信息，请参阅 “监视复制”。
高可用性： 只读副本无法启用高可用性，在升级副本时，它们也没有高可用性。 升级副本后，你负责配置高可用性。
有关适用于只读副本提升过程的其他注意事项，请参阅 Azure Database for PostgreSQL 中的只读副本提升 - 注意事项。
Cost
读副本会产生计算和存储成本，以及复制的跨区域数据传输费用。 有关详细的定价信息，请参阅 Azure Database for PostgreSQL 定价 和 带宽定价。
配置多区域支持
创建只读副本： 若要了解如何创建只读副本，请参阅 “创建只读副本”。 只要主服务器正在运行且可访问，就可以在创建主服务器后配置副本。
若要创建虚拟终结点，请参阅 “创建虚拟终结点”。
删除只读副本： 若要了解如何删除只读副本，请参阅 “删除只读副本”。
当所有区域都正常时的行为
本部分介绍在使用另一个区域和虚拟终结点中的只读副本配置服务器时会发生什么情况，并且所有区域都正常运行：
区域之间的流量路由： 在正常操作中，虚拟终结点将读写终结点的流量定向到主要区域中的主服务器。 如果还使用虚拟终结点的只读终结点，则会将流量定向到所配置的副本。
区域之间的数据复制： 跨区域只读副本使用异步复制来最大程度地减少对主服务器性能的影响。 复制滞后时间取决于多种因素，包括写入负载和主服务器和副本之间的延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。
区域故障期间的行为
本节介绍当服务器配置了另一个区域中的只读副本和虚拟终结点，而主要区域发生故障时，会发生什么情况：
检测和响应： 你需要负责检测主要区域的中断，并手动将只读副本提升为新的主服务器。 在区域中断期间，必须执行强制升级，这会导致任何未复制的数据丢失。
重要
你负责触发促销。 即使发生区域性故障，Azure 也不会自动提升只读副本。
有关启动升级的详细步骤，请参阅 将只读副本切换到主副本。
通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 删除与主要区域的所有活动连接。 完成升级过程后，应用程序需要重试与已升级副本的连接。
预期数据丢失： 在区域中断期间，必须执行强制升级，这会导致任何未复制的数据永久丢失。
数据丢失量取决于服务中断时的复制延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。
预期的停机时间： 强制升级通常在触发后的 1-3 分钟内完成。 应用程序可能还需要重新连接到正确的终结点。 虚拟终结点作为强制升级过程的一部分进行更新。 应用程序应遵循终结点 DNS 记录的生存时间（TTL），以确保在升级完成后快速重新连接到正确的副本。
流量重新路由： 服务器的虚拟终结点会自动将应用程序流量重定向到新的主副本。
注释
将只读副本提升为主服务器后，它未启用高可用性配置。 需要手动启用高可用性配置，或将其添加到自己的自动化进程。
区域恢复
使用虚拟终结点时，主要区域恢复后，旧的主服务器会自动配置为只读副本。 可以执行另一个提升操作，将主操作返回到您首选的主要区域。
针对区域故障进行测试
定期测试只读副本升级过程，以确保你的进程有效，并且这些功能符合 RTO 和 RPO 要求。
即使所有区域状态正常，也可以随时将只读副本提升为主服务器。 用于测试：
- 可以执行强制升级测试。 建议在非生产环境中执行这些测试，因为这可能会导致数据丢失。 强制升级测试有助于模拟在区域中断期间看到的行为。
- 对于计划内维护或想要避免数据丢失的测试方案，请改用计划的升级。 请注意，计划升级遵循与区域中断期间升级不同的过程。
有关分步说明，请参阅 将只读副本切换到主副本。
作为灾难恢复策略的一部分，定期运行完整恢复演练。 这些演练应包括数据验证、应用程序功能测试和记录的回滚过程。
备份和还原
Azure Database for PostgreSQL 会自动执行备份，这些备份提供时间点恢复功能，并帮助防止意外损坏和删除数据。 备份由Microsoft完全管理，不会中断服务器的可用性，并包括完整备份和事务日志备份。
备份存储： 如果服务器配置了区域冗余高可用性，备份将存储在区域冗余存储（ZRS）中。 对于未配置高可用性或具有区域（单区域）高可用性的服务器，备份存储在本地冗余存储（LRS） 中。
在具有对的 Azure 区域中，可以在服务器创建时配置 异地冗余（GRS）备份存储 ，以将备份复制到 Azure 配对区域，以便针对区域故障提供额外的保护。 备份以异步方式复制。
默认备份保留期为 7 天，此选项可将保留期延长至 35 天。 还可以使用 Azure 备份服务将手动创建的备份进行长达 10 年的长期存储。 所有备份均已加密。
恢复： 时间点恢复允许将数据库还原到备份保留期内的任何时刻。 还原过程使用新的用户提供的服务器名称创建新的数据库服务器，然后可以使用 as-is 或从中复制数据。
还原异地冗余备份时，将在配对区域中创建新的服务器。
此功能可用于从意外的数据修改、应用程序错误或测试方案中恢复。
对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。
有关详细信息，请参阅 Azure Database for PostgreSQL 中的备份和还原。
服务维护期间的系统弹性能力
Azure Database for PostgreSQL 会自动处理关键服务任务，包括修补基础硬件、操作系统和数据库引擎。 该服务包括安全更新、软件更新和次要版本升级，作为计划内维护的一部分。
若要确保服务器在维护时段内保持可用状态，请遵循以下建议：
启用高可用性： 在维护期间，可能需要在更新过程中重启服务器。 如果已启用高可用性，维护操作通常使用滚动更新来最大程度地减少停机时间。 定期维护活动（例如次要版本升级）首先在备用副本上发生。 为了减少停机时间，将备用节点提升为主节点，以确保在剩余节点进行维护任务时，工作负载可以继续运行。 无论服务器使用区域冗余还是区域高可用性，此排序都适用。
对于未启用高可用性的服务器，预计会在维护操作期间出现短暂的停机。 启用高可用性后，维护操作通常会以最少或无停机时间完成。
配置自定义维护时段： 可以将维护计划配置为系统管理，或定义自定义维护时段，以最大程度地减少对业务运营的影响。 在低活动期间计划维护，以最大程度地减少业务影响。 有关详细信息，请参阅 计划维护。
实现重试逻辑： 确保应用程序可以处理维护重启期间可能发生的短暂连接中断。 若要使应用程序能够复原这些类型的问题，请参阅 “暂时性故障复原” 指南。
服务级别协议
Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 联机服务的 SLA。
Azure Database for PostgreSQL 根据服务器的配置提供不同的可用性 SLA：
- 配置有区域冗余高可用性的服务器。
- 配置有区域（单区域）高可用性的服务器。
- 未配置高可用性的服务器。
相关内容
- Azure 可靠性
- Azure Database for PostgreSQL 的体系结构最佳做法
- Azure Database for PostgreSQL 业务连续性概览
- Azure Database for PostgreSQL 中的异地灾难恢复
- Azure Database for PostgreSQL 复原解决方案加速器 - Terraform 脚本，以实现本文中所述的许多复原和可恢复性原则。