Azure SQL Managed Instance业务连续性概述

applies to：Azure SQL Managed Instance

本文概述了Azure SQL Managed Instance的业务连续性和灾难恢复功能，介绍了从中断事件中恢复的选项和建议，这些事件可能导致数据丢失或导致实例和应用程序不可用。 了解当用户或应用程序错误影响数据完整性、Azure可用性区域或区域中断或应用程序需要维护时该怎么办。

概述

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

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

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

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

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

高可用性

Azure SQL Managed Instance具有核心复原能力和可靠性承诺，可防范软件或硬件故障。 自动化数据库备份，以保护数据免受损坏或意外删除。 作为平台即服务（PaaS），Azure SQL Managed Instance服务以现成的功能提供可用性，并提供 enterprise 类可用性 SLA。

若要在 Azure 云环境中实现高可用性，请启用 zone 冗余。 使用区域冗余时，实例使用 可用性区域 来确保对区域性故障的复原能力。

• 许多Azure区域提供可用性区域，这些区域是具有独立电源、冷却和网络基础结构的区域内的数据中心组。
• 可用性区域旨在当一个区域出现中断时，在其余区域提供区域服务、容量和高可用性。

通过启用区域冗余，实例就具有了区域硬件和软件故障复原能力，并且这种恢复对应用程序透明。 启用高可用性后，Azure SQL Managed Instance服务能够提供更高的可用性 SLA。

灾难恢复

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

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

RTO 和 RPO

制定业务连续性计划时，请了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 量化灾难恢复业务需求的两种常见方法是：

• 恢复时间目标（RTO）：应用程序在计划外中断事件后完全恢复所需的时间。
• 恢复点目标（RPO）：可以从计划外中断事件中容忍的数据丢失的时间量。

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

可提供业务连续性的功能

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

在同一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 副本

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

如果为仅灾难恢复指定辅助实例，并且实例上未运行读取或写入工作负荷，Azure会提供在故障转移权限权益下免费向主实例授予的 vCore 数。 你仍需为辅助实例使用的计算和存储付费。 有关混合故障转移权限福利的详细条款和条件，请参阅 “SQL Server - 故障转移权限”部分中的在线SQL Server许可条款。

福利的名称取决于您的情境：

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

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

图示用于比较 Azure SQL 托管实例的故障转移权限。

后续步骤

相关内容

• Azure SQL 托管实例中的自动备份
• 故障转移组
• 恢复数据库
• 启用区域冗余