执行灾难恢复演练 - Azure SQL 托管实例

适用于：Azure SQL 托管实例

应定期测试和验证应用程序是否准备好恢复工作流。 验证应用程序的行为以及数据丢失和/或涉及到故障转移的中断所造成的影响，是一种良好的工程实践。 这也是大多数行业标准的要求，作为业务连续性认证的一部分。

执行灾难恢复演练的操作包括：

• 模拟数据层中断
• 恢复
• 验证恢复后的应用程序完整性
• 故障回复到原始实例（可选）

根据针对业务连续性设计应用程序的方式，用于执行演练的工作流会有所不同。 本文介绍在 Azure SQL 托管实例上下文中执行灾难恢复演练的最佳做法。

若要防止执行灾难恢复演练时发生潜在的数据丢失，请通过创建生产环境的副本在测试环境中执行演练，并使用测试环境来验证应用程序的故障转移工作流。

若要模拟中断，可重命名源数据库。 此名称更改会导致应用程序连接失败。

• 按照灾难恢复指南中所述，将数据库异地还原到其他实例。
• 更改应用程序配置以连接到已恢复的实例，并按照在恢复后配置数据库指南完成恢复。

通过验证恢复后的应用程序完整性（包括连接字符串、登录名、基本功能测试或其他标准应用程序注销过程的其他验证部分）来完成演练。

使用异地还原时，故障回复包括将应用程序重新指向原始实例。

对于故障转移组保护的实例，演练过程包括按计划故障转移到辅助实例。 计划的故障转移可确保在切换角色后故障转移组中的主实例和辅助实例保持同步。 与非计划的故障转移不同，此操作不会导致数据丢失，因此可以在生产环境中执行演练。

使用符合业务需求的故障转移策略配置故障转移组，并测试故障转移，而不必考虑故障转移策略是如何配置的。 有关详细信息，请参阅测试故障转移。 建议使用客户管理的故障转移策略来控制故障转移过程。

若要模拟中断，可以禁用已连接到数据库的 Web 应用程序或虚拟机。 此中断模拟会导致 Web 客户端连接失败。

• 确保 DR 区域中的应用程序配置指向以前的辅助数据库，故障转移后，该数据库将成为完全可访问的新主数据库。
• 启动故障转移组从辅助实例进行的计划内故障转移。
• 按照在恢复后配置数据库指南完成恢复。

通过验证恢复后的应用程序完整性（包括连接性、基本功能测试，或演练验收所需的其他验证）来完成演练。

若要进行故障回复，请对故障转移组执行计划的故障转移，以将其回复到原始主实例。 由于应用程序已配置为指向故障转移组终结点，因此无需进一步更改。 故障转移组终结点在故障转移后自动将流量路由到新的主实例。

故障回复是可选的。 如果不需要故障回复，可以将辅助实例保留为新的主实例。

可以使用 托管实例链接 进行灾难恢复。 双向故障转移仅在 SQL Server 2022 及配置了 SQL Server 2022 更新策略的实例中支持。 SQL Server 2019 及更低版本仅支持单向故障转移，而不支持故障回复到 SQL Server。

本部分介绍如何使用 SQL Server 2022 执行灾难恢复演练。 使用托管实例链接进行灾难恢复时，演练涉及到按计划故障转移到辅助实例。 计划的故障转移可确保在切换角色时，托管实例链接中的主实例和辅助实例保持同步。 与非计划的故障转移不同，此操作不会导致数据丢失，因此可以在生产环境中执行演练。

若要模拟中断，请禁用与通过链接复制的数据库的主要副本的客户端连接。 此中断模拟会导致数据库客户端（应用程序）的连接失败。

对于恢复，请执行以下步骤：

1. 启动到辅助实例的按计划链接故障转移。
2. 将受影响的应用程序重新指向新的主实例。

若要进行验证，请执行以下作：

1. 在新的主实例上执行应用程序连接和读/写测试。
2. （可选）验证在钻取期间写入的测试数据是否复制到辅助实例。

若要进行故障回复，请对托管实例链接执行计划的故障转移，以将其回复到原始主实例。 故障转移后，应用程序必须重新指向原始主实例。

故障回复是可选的。 如果不需要故障回复，可以将辅助实例保留为新的主实例。

若要了解详细信息，请查看：

• 连续性方案。
• 自动备份
• 从服务启动的备份还原数据库。
• 故障转移组。
• 灾难恢复指南
• 高可用性和灾难恢复清单。