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

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

适用于： Azure SQL 托管实例

• Azure SQL 数据库
• Azure SQL 托管实例

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

概述

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

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

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

可用性

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

高可用性

要在 Azure 云环境中实现高可用性，请启用区域冗余，以便实例使用可用性区域来确保对区域故障的复原能力。 许多 Azure 区域可提供可用性区域，这些区域是一个区域内的独立数据中心组，具有独立的电源、冷却和网络基础结构。 可用性区域旨在当一个区域出现中断时，在其余区域提供区域服务、容量和高可用性。 通过启用区域冗余，实例就具有了区域硬件和软件故障复原能力，并且这种恢复对应用程序透明。 当启用高可用性时，Azure SQL 托管实例服务能够提供高达 99.99% 的更高可用性 SLA。

灾难恢复

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

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

可提供业务连续性的功能

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

业务中断应用场景	业务连续性功能
影响数据库节点的本地硬件或软件故障。	为了缓解本地硬件和软件故障问题，SQL 托管实例包含一个可用性体系结构，可以保证在出现这些故障时自动进行恢复，其可用性 SLA 高达 99.99%。
通常由应用程序 bug 或人为失误导致的数据损坏或删除。 此类故障特定于应用程序，通常无法通过服务检测到。	为了防止企业丢失数据，SQL 托管实例每周自动创建完整数据库备份，每 12 或 24 小时自动创建差异数据库备份，每隔 5 - 10 分钟自动创建事务日志备份。 默认情况下，备份将在异地冗余存储中存储七天，并支持长达 35 天的时间点还原可配置备份保留期。 如果实例尚未删除，或者已配置长期保留，可将已删除的数据库还原到删除时的时间点。
罕见的由自然灾害事件、配置更改、软件错误或硬件组件故障引起的数据中心或可用性区域中断。	若要缓解数据中心或可用性区域级别的中断，请为 SQL 托管实例启用区域冗余，以使用 Azure 可用性区域，并在 Azure 区域内的多个物理区域之间提供冗余。 启用区域冗余可确保托管实例能够具有高达 99.99% 的高可用性 SLA 区域性故障复原能力。
罕见的由灾难性自然灾害事件引起的影响所有可用性区域及其组成的数据中心的区域中断。	若要缓解区域范围内的中断，请使用以下选项之一启用灾难恢复： - 与故障转移组进行连续数据同步，同步到用于故障转移的次要区域中的副本。 - 将备份存储冗余设置为“异地冗余备份存储”，以使用异地还原。

RTO 和 RPO

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

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

业务连续性选项	RTO（故障时间）	RPO（无数据丢失）
高可用性 （使用区域冗余）	通常不到30秒	0
灾难恢复 （将故障转移组与客户管理的故障转移策略配合使用）	通常不到60秒	等于或大于 0 （取决于数据更改之前尚未副本的中断事件）
使用异地还原进行灾难恢复	12 小时	1 小时

业务连续性检查列表

有关最大化可用性并实现更高业务连续性的规范性建议，请参阅：

• 可用性核对清单
• 高可用性清单
• 灾难恢复清单

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

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

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

将数据库恢复到现有实例

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

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

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

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

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

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

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

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

为中断做好准备

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

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

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

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

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

注意

当数据中心恢复联机，旧主实例自动重新连接至新主实例，以转为辅助实例。 如果需要将主数据库重定位至原始区域，可以手动启动计划的故障转移（故障回复）。

执行异地还原

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

注意

如果数据中心在应用程序切换到恢复的数据库之前就重新联机，可以取消恢复。

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

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

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

注意

如果使用故障转移组并使用读写侦听器连接到实例，则在故障转移后应用程序将自动透明地进行重定向。

无许可证 DR 副本

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

如果将辅助实例指定为仅用于灾难恢复，并且实例上未运行读取或写入工作负载，则 Microsoft 会根据故障转移权限权益，免费提供许可主实例的 vCore 数。 你仍需为辅助实例使用的计算和存储付费。 有关混合故障转移权限权益的确切条款和条件，请参阅“SQL Server – 故障转移权限”一节中的 SQL Server 在线许可条款。

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

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

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

后续步骤

若要详细了解业务连续性功能，请参阅自动备份和故障转移组。 有关灾难恢复，请参阅 Azure SQL 托管实例的恢复数据库和启用区域冗余。