你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
为 SQL Server 设置灾难恢复
本文介绍如何帮助保护应用程序的 SQL Server 后端。 为此，可以结合使用 SQL Server 业务连续性和灾难恢复 (BCDR) 技术与 Azure Site Recovery。
在开始之前，请确保了解 SQL Server 灾难恢复功能。 这些功能包括：
- 故障转移群集
- Always On 可用性组
- 数据库镜像
- 日志传送
- 活动异地复制
- 自动故障转移组
将 BCDR 技术与 Site Recovery 相结合
应该根据下表中所述的恢复时间目标 (RTO) 和恢复点目标 (RPO) 需求，选择适当的 BCDR 技术来恢复 SQL Server 实例。 将 Site Recovery 与所选技术的故障转移操作相结合，以协调整个应用程序的恢复。
| 部署类型 | BCDR 技术 | SQL Server 的预期 RTO | SQL Server 的预期 RPO |
|---|---|---|---|
| Azure 基础结构即服务 (IaaS) 虚拟机 (VM) 上的或本地的 SQL Server。 | Always On 可用性组 | 将次要副本设为主要副本所花费的时间。 | 由于复制到次要副本是一种异步操作，因此会有一定的数据丢失。 |
| Azure IaaS VM 上的或本地的 SQL Server。 | 故障转移群集 (Always On FCI) | 在节点之间进行故障转移所花费的时间。 | 由于 Always On FCI 使用共享存储，因此故障转移时会提供相同的存储实例视图。 |
| Azure IaaS VM 上的或本地的 SQL Server。 | 数据库镜像（高性能模式） | 强制服务所花费的时间，使用镜像服务器作为温备用服务器。 | 复制是异步的。 镜像数据库可能稍微滞后于主体数据库。 滞后时间通常很小。 但是，如果主体或镜像服务器的系统负载过大，则滞后时间可能很大。 日志传送可用作数据库镜像的补充。 它是异步数据库镜像的理想替代方案。 |
| Azure 上的 SQL 平台即服务 (PaaS)。 此部署类型包括单一数据库和弹性池。 |
活动异地复制 | 触发故障转移后持续 30 秒。 对一个辅助数据库激活故障转移后，所有其他辅助数据库将自动链接到新的主数据库。 |
5 秒 RPO。 活动异地复制使用 SQL Server 的 Always On 技术。 它使用快照隔离以异步方式将主数据库上已提交的事务复制到辅助数据库。 保证辅助数据永不包含部分事务。 |
| Azure 上配置了活动异地复制的 SQL as PaaS。 此部署类型包括托管实例、弹性池和单一数据库。 |
自动故障转移组 | 1 小时 RTO。 | 5 秒 RPO。 自动故障转移组在活动异地复制的顶层提供组语义。 但使用相同的异步复制机制。 |
| Azure IaaS VM 上的或本地的 SQL Server。 | 使用 Azure Site Recovery 进行复制 | RTO 通常小于 15 分钟。 有关详细信息，请阅读 Site Recovery 提供的 RTO SLA。 | 为应用程序一致性提供 1 小时保证，为崩溃一致性提供 5 分钟保证。 若要寻求降低 RPO，请使用其他 BCDR 技术。 |
注意
使用 Site Recovery 帮助保护 SQL 工作负荷时需要考虑到几个重要因素：
- Site Recovery 是应用程序不可知的。 Azure Site Recovery 可帮助保护部署在受支持操作系统上的任何 SQL Server 版本。 有关详细信息，请参阅复制的计算机的恢复支持矩阵。
- 对于 Azure、Hyper-V、VMware 或物理基础结构中的任何部署，都可以选择使用 Site Recovery。 请遵照本文档末尾的指导来了解如何使用 Site Recovery 帮助保护 SQL Server 群集。
- 确保在计算机上观测到的数据更改率在 Site Recovery 限制范围内。 更改率以每秒写入字节数度量。 对于运行 Windows 的计算机，可以选择任务管理器中的“性能”选项卡来查看此更改率。 观测每个磁盘的写入速度。
- Site Recovery 支持复制存储空间直通上的故障转移群集实例。 有关详细信息，请参阅如何启用存储空间直通复制。
将 SQL 工作负载迁移到 Azure 时，建议应用 Azure 虚拟机上的 SQL Server 的性能准则。
应用程序的灾难恢复
Site Recovery 借助恢复计划来协调整个应用程序的测试故障转移和故障转移。
需要满足一些先决条件才能确保根据需要完全自定义恢复计划。 任何 SQL Server 部署通常都需要一个 Active Directory 部署。 它还需要应用层的连接。
步骤 1：设置 Active Directory
在辅助恢复站点上安装 Active Directory，使 SQL Server 能够正常运行。
- 小型企业：有几个应用和适用于本地站点的单个域控制器。 若要故障转移整个站点，请使用 Site Recovery 复制。 此服务会将域控制器复制到辅助数据中心或 Azure。
- 大中型企业：你可能需要设置其他域控制器。
- 如果你有大量的应用程序、使用 Active Directory 林，并且想要按应用程序或工作负荷进行故障转移，请在辅助数据中心或 Azure 中设置另一个域控制器。
- 如果你使用 Always On 可用性组恢复到远程站点，请在辅助站点或 Azure 中设置另一个域控制器。 此域控制器供已恢复的 SQL Server 实例使用。
本文中的说明假设辅助位置中提供了域控制器。 有关详细信息，请参阅使用 Site Recovery 帮助保护 Active Directory 的过程。
步骤 2：确保与其他层建立连接
在目标 Azure 区域中运行数据库层后，确保与应用层和 Web 层建立连接。 提前采取必要的步骤来验证与测试故障转移建立的连接。
通过以下示例了解如何根据连接注意事项设计应用程序：
步骤 3：与 Always On、活动异地复制和自动故障转移组互操作
BCDR 技术 Always On、活动异地复制和自动故障转移组为目标 Azure 区域中运行的 SQL Server 提供辅助副本。 应用程序故障转移的第一步是将此副本指定为主副本。 此步骤假设次要区域中已有一个域控制器。 如果你选择执行自动故障转移，则可能不需要执行该步骤。 只有在完成数据库故障转移后，才故障转移 Web 层和应用层。
注意
如果已使用 Site Recovery 来帮助保护 SQL 计算机，则只需创建这些计算机的恢复组，并在恢复计划中添加其故障转移。
使用应用层和 Web 层虚拟机创建恢复计划。 以下步骤说明如何添加数据库层的故障转移：
导入相应的脚本，用于在资源管理器虚拟机和经典虚拟机中对 SQL 可用性组进行故障转移。 将脚本导入到 Azure 自动化帐户中。
将 ASR-SQL-FailoverAG 脚本添加为恢复计划的第一个组的准备操作。
遵照脚本中的说明创建自动化变量。 此变量提供可用性组的名称。
步骤 4：执行测试故障转移
某些 BCDR 技术（例如 SQL Always On）原生并不支持测试故障转移。 我们建议仅在使用此类技术时才运用以下方法。
在 Azure 中托管可用性组副本的 VM 上设置 Azure 备份。
触发对恢复计划进行测试故障转移之前，请从上一步骤中进行的备份恢复 VM。
在从备份还原的 VM 中强制仲裁。
将侦听器的 IP 地址更新为测试故障转移网络中的可用地址。
使侦听器联机。
确保故障转移网络中的负载均衡器有一个 IP 地址，它来自与每个可用性组侦听器对应的前端 IP 地址池，以及后端池中的 SQL Server VM。
在后续恢复组中，依次为此恢复计划中的应用层和 Web 层添加故障转移。
执行恢复计划的测试性故障转移，以测试应用程序的端到端故障转移。
执行故障转移的步骤
在步骤 3 中添加脚本并在步骤 4 中验证该脚本后，可以执行步骤 3 中创建的恢复计划的故障转移。
在测试故障转移和故障转移恢复计划中，应用层和 Web 层的故障转移步骤应该相同。
如何帮助保护 SQL Server 群集
对于运行 SQL Server Standard Edition 或 SQL Server 2008 R2 的群集，建议使用 Site Recovery 复制来帮助保护 SQL Server。
Azure 到 Azure，以及本地到 Azure
复制到 Azure 区域时，Site Recovery 不支持来宾群集。 SQL Server Standard Edition 也不提供低成本灾难恢复解决方案。 在此方案中，我们建议在主要位置的独立 SQL Server 实例中保护 SQL Server 群集，并在次要位置恢复它。
在主要 Azure 区域或本地站点中配置另一个独立 SQL Server 实例。
将此实例配置为需要帮助保护的数据库的镜像。 在高安全模式下配置镜像。
在主要站点上为 Azure、Hyper-V 或 VMware VM 和物理服务器配置 Site Recovery。
使用 Site Recovery 复制将新的 SQL Server 实例复制到次要站点。 由于该实例是高安全性镜像副本，因此它会与主群集同步，但使用 Site Recovery 复制来进行复制。
故障回复注意事项
对于 SQL Server Standard 群集，完成计划外故障转移后进行故障回复需要执行 SQL Server 备份和还原。 从镜像实例对原始群集执行此操作，并重建镜像。
常见问题
与 Site Recovery 配合使用时如何获得 SQL Server 的授权？
SQL Server 的 Site Recovery 复制已涵盖在“软件保障 - 灾难恢复”权益中。 这项权益适用于所有 Site Recovery 方案：本地到 Azure 的灾难恢复，以及跨区域的 Azure IaaS 灾难恢复。 有关详细信息，请参阅 Azure Site Recovery 定价。
Site Recovery 是否支持我的 SQL Server 版本？
Site Recovery 是应用程序不可知的。 Azure Site Recovery 可帮助保护部署在受支持操作系统上的任何 SQL Server 版本。 有关详细信息，请参阅复制的计算机的恢复支持矩阵。
Azure Site Recovery 是否适用于 SQL 事务复制？
由于 Azure Site Recovery 使用文件级复制，SQL 无法保证关联的 SQL 复制拓扑中的服务器会在 Azure Site Recovery 故障转移时同步。 这可能会导致日志读取器和/或分发代理由于 LSN 不匹配而失败，因而中断复制。 如果在复制拓扑中对发布服务器、分发服务器或订阅服务器进行故障转移，则需要重新生成复制。 建议重新初始化对 SQL Server 的订阅。
后续步骤
- 详细了解 Site Recovery 体系结构。
- 对于 Azure 中的 SQL 服务器，请详细了解适用于次要 Azure 区域中的恢复的高可用性解决方案。
- 对于 SQL 数据库，请详细了解适用于次要 Azure 区域中的恢复的业务连续性和高可用性选项。
- 对于本地的 SQL Server 计算机，请详细了解适用于 Azure 虚拟机中的恢复的高可用性选项。