使用 Azure SQL 托管实例确保业务连续性的相关概述

适用于：Azure SQL 托管实例

本文章概述了 Azure SQL 托管实例的业务连续性和灾难恢复功能，描述了从可能导致数据丢失或导致实例和应用程序离线的中断事件中恢复的选项和建议。 了解对一些情况的处理方式，包括用户或应用程序错误影响数据完整性、Azure 可用性区域或区域发生服务中断，或者应用程序需要维护。

概述

Azure SQL 托管实例中的业务连续性是指通过提供可用性、高可用性和灾难恢复，使业务在面临中断时能够继续运营的机制、策略和过程。

在大多数情况下，SQL 托管实例处理云环境中可能发生的中断事件，并让应用程序和业务流程保持运行。 然而，在一些破坏性事件中，缓解措施可能需要一些时间，例如：

• 用户意外删除或更新了表中的某行。
• 恶意攻击者成功删除了数据或数据库。
• 灾难性自然灾害事件导致数据中心或可用性区域或区域瘫痪。
• 罕见的由配置更改、软件错误或硬件组件故障引起的数据中心、可用性区域或区域性中断。

可用性

Azure SQL 托管实例具有核心复原能力和可靠性承诺，可保护其免受软件或硬件故障的影响。 自动化数据库备份，以保护数据免受损坏或意外删除。 作为一种平台即服务 (PaaS)，Azure SQL 托管实例服务可提供现成的可用性功能，可用性 SLA 高达 99.99%，行业领先。

灾难恢复

若要实现跨区域的更高可用性和冗余性，可以启用灾难恢复功能，以便从灾难性的区域故障中快速恢复实例。 使用 Azure SQL 托管实例进行灾难恢复的选项包括：

• 故障转移组可实现主实例和辅助实例之间的连续同步。 故障转移组可提供保持不变的读写和只读侦听器端点，因此无需在故障转移后更新应用程序连接字符串。
• 异地还原允许在无法通过在任何 Azure 区域中的任何现有实例上创建新数据库来访问主要区域中的数据库时，通过从异地复制备份中恢复来从区域中断中恢复。

可提供业务连续性的功能

对于一个实例，主要有四种潜在的中断场景。 下表列出了可用于缓解潜在业务中断应用场景的 SQL 托管实例业务连续性功能：

RTO 和 RPO

制定业务连续性计划时，请了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 应用程序完全恢复所需的时间称为“恢复时间目标”(RTO)。 还要了解从计划外中断事件恢复时，应用程序可忍受最近数据更新丢失的最长期限（时间间隔）。 可能的数据丢失称为恢复点目标 (RPO)。

下表比较了每个业务连续性选项的 RPO 和 RTO：

恢复同一 Azure 区域内的数据库

可以使用自动数据库备份将数据库还原到过去的某个时间点。 可以通过这种方式从人为错误导致的数据损坏中恢复。 可以通过时间点还原 (PITR) 在同一实例或不同实例中创建一个新数据库，以表示损坏事件发生之前的数据状态。 还原操作是一个数据操作的大小，还取决于目标实例的当前工作负荷。 恢复非常大或非常活跃的数据库可能需要更长时间。 有关恢复时间的详细信息，请参阅数据库恢复时间。

如果支持的最长时间点还原 (PITR) 备份保留期对你的应用程序而言不足，则可以通过为数据库配置长期保留 (LTR) 策略来延长保留期。 有关详细信息，请参阅长期备份保留。

将数据库恢复到现有实例

Azure 数据中心会罕见地发生中断。 发生中断时，业务可能仅中断几分钟，也可能持续数小时。

• 一个选项是等待数据中心中断结束时，实例重新联机。 这适用于可以容忍数据库脱机的应用程序。 例如无需一直处理的开发项目或免费试用版。 数据中心中断时，不知道中断会持续多久，因此该选项仅适用于在一段时间内不需要数据库的情况。
• 如果使用异地冗余 (GRS) 存储，另一种方法是使用异地冗余数据库备份（异地还原）将数据库还原到任何 Azure 区域中的任何 SQL 托管实例。 异地还原使用异地冗余备份作为源，即使由于停电而无法访问数据库或数据中心，也依然能够用其将数据库恢复到上次可用的时间点。 可以在配对区域中找到可用的备份。
• 最后，如果已将故障转移组用于实例，则可以通过客户（推荐）或 Azure 托管故障转移从中断中快速恢复。 虽然故障转移本身只需几秒钟即可完成，但该服务至少需要 1 小时才能激活 Azure 托管异地故障转移（如果已配置）。 这是确保故障转移符合中断规模所必需的。 此外，由于配对区域之间异步复制的性质，故障转移可能会导致最近更改的数据丢失。

制定业务连续性计划时，需了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 应用程序完全恢复所需的时间称为恢复时间目标 (RTO)。 此外，还需要了解从计划外中断事件恢复时，应用程序可忍受最近数据更新丢失的最长期限（时间间隔）。 可能的数据丢失称为恢复点目标 (RPO)。

不同的恢复方法提供不同级别的 RPO 和 RTO。 可以选择特定的恢复方法，也可以使用各种方法的组合，以便实现应用程序的完全恢复。

如果应用程序符合以下任意条件，请使用故障转移组：

• 是任务关键型应用程序。
• 具有服务级别协议 (SLA)，不允许停机 12 小时或更长时间。
• 停机可能导致财务责任。
• 具有很高的数据更改率，而且不接受丢失 1 小时的数据。
• 活动异地复制的额外成本低于潜在财务责任和相关业务损失所付出的代价。

可以根据应用程序需求，选择使用数据库备份和故障转移组的组合。

以下各节概述使用数据库备份或故障转移组进行恢复的步骤。

为中断做好准备

无论使用哪种业务连续性功能，都必须：

• 识别并准备目标实例，包括网络 IP 防火墙规则、登录名和 master 数据库级权限。
• 确定如何将客户端和客户端应用程序重定向到新实例
• 记录其他依赖项，例如审核设置和警报

如果准备不适当，故障转移或恢复数据库后，需要花更多时间让应用程序联机，还有可能要在这种情况下进行故障排除 - 可谓雪上加霜。

故障转移到异地复制的辅助实例

如果使用故障转移组作为恢复机制，则可以配置自动故障转移策略。 启用后，辅助实例通过故障转移提升为新的主实例，它可以记录新事务并响应查询 - 仅丢失极少尚未复制的数据。

执行异地还原

如果将自动备份与异地冗余存储（创建实例时的默认存储选项）一起使用，则可以使用异地还原来恢复数据库。 恢复通常在 12 小时内进行 - 最多丢失 1 小时的数据，具体取决于上次日志备份的执行和复制时间。 在恢复完成之前，数据库无法记录任何事务或响应任何查询。 请注意，异地还原仅将数据库还原到上一个可用时间点。

执行故障转移/恢复后任务

从任一恢复机制恢复后，都必须执行以下附加任务，用户和应用程序才能重新运行：

• 将客户端和客户端应用程序重定向到新实例和还原的数据库。
• 对于要进行连接的用户，请确保设置适当的网络 IP 防火墙规则。
• 确保设置适当的登录名和 master 数据库级权限（或使用包含用户）。
• 视情况配置审核。
• 视情况配置警报。

无许可证 DR 副本

将辅助 Azure SQL 托管实例配置为仅用于灾难恢复 (DR)，以节省许可成本。 如果在两个 SQL 托管实例之间使用故障转移组，或者在 SQL Server 和 Azure SQL 托管实例之间配置了混合链接，则可以使用此权益。 只要辅助实例上没有任何读取或写入工作负荷，并且只是被动 DR 备用实例，就不会向你收取辅助实例使用的 vCore 许可费用。

如果你指定将某个辅助实例仅用于灾难恢复，并且该实例上未运行读取或写入工作负荷，则 Azure 将根据故障转移权利权益，为你提供许可给主实例的 vCore 数量而不收取额外的费用。 你仍需为辅助实例使用的计算和存储付费。 有关混合故障转移权利权益的精确条款和条件，请参阅“SQL Server � 故障转移权利”部分中联机的 SQL Server 许可条款。

权益的名称取决于你的方案：

• 被动副本的混合故障转移权限：配置 SQL Server 和 Azure SQL 托管实例之间的链接时，可以使用混合故障转移权限权益来节省被动次要副本的 vCore 许可成本。
• 备用副本的故障转移权限：在两个托管实例之间配置故障转移组时，可以使用故障转移权限权益来节省备用次要副本的 vCore 许可成本。

下图演示了每种方案的权益：

后续步骤

若要详细了解业务连续性功能，请参阅自动备份和故障转移组。 有关灾难恢复，请参阅恢复数据库。