通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Database for PostgreSQL 灵活服务器中的异地复制

  • 项目

适用于： Azure Database for PostgreSQL 灵活服务器

可以在主服务器所在的同一区域和不同区域中创建只读副本。 对于灾难恢复计划或让数据更贴近用户等场景，异地复制很有帮助。

你可以在任何 Azure Database for PostgreSQL 灵活服务器区域中拥有主服务器。 主服务器也可以在支持 Azure Database for PostgreSQL 灵活服务器的任何 Azure 全球区域中拥有副本。 此外，我们还支持特殊区域：Azure 政府和由世纪互联运营的 Microsoft Azure。 现在支持的特殊区域包括：

  • Azure 政府区域：

    • US Gov 亚利桑那州
    • US Gov 德克萨斯州
    • US Gov 弗吉尼亚州

  • 由世纪互联运营的 Microsoft Azure 区域：

    • 中国北部 3
    • 中国东部 3
    • 中国北部 2
    • 中国东部 2

用于灾难恢复的配对区域

虽然可以在任何受支持的区域中创建副本，但在配对区域中选择副本可以带来明显的好处，尤其是出于灾难恢复目的设计体系结构时：

  • 区域恢复顺序：整个地理区域发生服务中断中，将优先恢复每个配对集中的一个区域，以确保跨配对区域的应用程序始终有一个区域可供快速恢复。

  • 按顺序更新：配对区域的更新按时间顺序交错进行，从而最大程度地降低更新相关问题导致停机的风险。

  • 物理隔离：配对区域中的不同数据中心至少保持 300 英里的距离，从而降低因重大事件而同时出现服务中断的风险。

  • 数据驻留：配对集中的区域驻留在同一地理位置（只有少数例外情况），可满足数据驻留要求。

  • 性能：虽然配对区域通常提供较低的网络延迟，从而增强数据易访问性和用户体验，但它们不一定是延迟绝对最低的区域。 如果主要目标是为更靠近用户的数据提供服务而不是优先考虑灾难恢复，则评估所有可用性区域的延迟至关重要。 在某些情况下，非配对区域的延迟可能是最低的。 若要进行全面的了解，可以参考 Azure 的往返延迟数据以做出明智的选择。

若要更深入地了解配对区域的优势，请参阅 Azure 有关跨区域复制的文档。

区域故障和恢复

各个区域的 Azure 设施都采用高可靠设计。 但是，在极少数情况下，由于网络故障或自然灾害等严重情况，可能无法访问整个区域。 Azure 的功能允许创建分布在多个区域的应用程序，以确保一个区域发生的故障不会影响其他区域。

为区域灾难做好准备

为潜在的区域灾难做好准备对于确保应用程序和服务的不间断运行至关重要。 如果考虑为 Azure Database for PostgreSQL 灵活服务器实例制定可靠的应变计划，以下是关键步骤和注意事项：

  1. 建立异地复制只读副本：必须在与主服务器不同的区域中设置只读副本。 这可以确保主要区域出现服务中断时保持业务连续性。
  2. 确保服务器对称性：“提升到主服务器”操作是处理区域服务中断时最建议的操作，但这需要满足服务器对称性要求。 这意味着主服务器和副本服务器必须具有相同的特定设置配置。 使用此操作的优点包括：
    • 如果使用虚拟终结点，则无需修改应用程序连接字符串。
    • 它提供了无缝恢复过程，一旦受影响的区域恢复联机，则原始主服务器就会自动恢复其功能，但会充当新的副本角色。
  3. 设置虚拟终结点：使用虚拟终结点可以在发生服务中断时，将应用程序顺利过渡到另一个区域。 无需对应用程序的连接字符串进行任何更改。
  4. 配置只读副本：并非主服务器中的所有设置都会复制到只读副本。 必须确保在只读副本上正确设置全部所需的配置和功能（例如 PgBouncer）。 有关详细信息，请参阅配置管理部分。
  5. 为高可用性 (HA) 做好准备：如果你的设置需要高可用性，请注意不会在提升的副本上自动启用此功能。 请准备好在提升后激活它。 考虑自动执行此步骤以最大程度地减少停机时间。
  6. 定期测试：定期模拟区域灾难场景以验证现有的阈值、目标和配置。 确保应用程序在这些测试场景中按预期做出响应。
  7. 遵循 Azure 的一般指南：Azure 提供了有关可靠性和灾难准备的综合指导。 查阅这些资源并将最佳做法整合到准备计划中会很有帮助。

主动提前为区域灾难做好准备可确保应用程序和数据的复原能力和可靠性。

当服务中断影响了 SLA 时

如果特定区域中的 Azure Database for PostgreSQL 灵活服务器出现长时间中断，威胁到应用程序的服务级别协议 (SLA)，请注意，下面讨论的两个操作都不是服务驱动的。 这两个操作都需要用户干预。 最佳做法是尽可能自动执行整个过程并采取可靠的监视方案。 若要详细了解服务中断期间会提供哪些信息，请参阅服务中断页。 在发生区域故障时，只能进行强制提升，这意味着数据丢失量大致等同于副本和主服务器之间的当前滞后时间。 因此，监视滞后时间至关重要。 考虑以下步骤：

提升到主服务器

如果配置了虚拟终结点，则此选项不需要更新应用程序中的连接字符串。 激活后，写入方终结点将重新指向不同区域中的新主服务器，并且 Azure 门户中的复制状态列将显示“正在重新配置”。 一旦受影响的区域还原，以前的主服务器将自动恢复，但现在会充当副本角色。

提升到独立服务器并从复制中删除

在这种情况下，这是唯一可行的选项。 提升服务器后，需要更新应用程序的连接字符串。 原始区域还原后，旧的主服务器可能再次变为活动状态。 请确保将其删除，以避免产生不必要的费用。 如果你希望保留以前的拓扑，请重新创建只读副本。

相关内容