使用 Azure SQL 数据库确保业务连续性的相关概述

适用于: Azure SQL 数据库 Azure SQL 托管实例

Azure SQL 数据库和 SQL 托管实例中的业务连续性是指在遇到中断(尤其是计算基础结构的中断)时,使企业能够继续运营的机制、策略和过程。 在大多数情况下,SQL 数据库和 SQL 托管实例将会处理云环境中可能发生的中断事件,并让应用程序和业务流程保持运行。 但是,SQL 数据库无法自动处理某些中断事件,例如:

  • 用户意外删除或更新了表中的某行。
  • 恶意攻击者成功删除了数据或数据库。
  • 地震导致断电和暂时性的数据中心停运。

本概述介绍 SQL 数据库和 SQL 托管实例针对业务连续性和灾难恢复所提供的功能。 了解用于从干扰性事件恢复的选项、建议和教程,这些事件可能导致数据丢失或者数据库和应用程序无法使用。 了解对一些情况的处理方式,包括用户或应用程序错误影响数据完整性、Azure 区域发生服务中断,或者应用程序需要维护。

有利于业务连续性的 SQL 数据库功能

从数据库角度看,主要有四种潜在的中断场景:

  • 影响数据库节点的本地硬件或软件故障,例如磁盘驱动器故障。
  • 通常由应用程序 bug 或人为失误导致的数据损坏或删除。 此类故障特定于应用程序,通常无法通过数据库服务检测到。
  • 可能由自然灾害造成的数据中心服务中断。 针对这种情况,需要采取某种程度的异地冗余,并将应用程序故障转移到备用数据中心。
  • 升级或维护错误 - 在执行计划内基础结构维护或升级期间发生意外的问题时,可能需要快速回退到以前的数据库状态。

为了缓解本地硬件和软件故障问题,SQL 数据库包含一个高可用性体系结构,可以保证在出现这些故障时自动进行恢复,其可用性 SLA 高达 99.995%。

为了防止企业丢失数据,SQL 数据库和 SQL 托管实例每周自动创建完整数据库备份,每 12 小时自动创建差异数据库备份,每隔 5 - 10 分钟自动创建事务日志备份。 所有服务层级的备份在 RA-GRS 存储中存储至少 7 天。 对于时间点还原,所有服务层级(“基本”除外)都支持可配置的备份保留期,最长为 35 天。

SQL 数据库和 SQL 托管实例还提供多种业务连续性功能,用于缓解各种计划外方案问题。

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

可以使用自动数据库备份将数据库还原到过去的某个时间点。 可以通过这种方式从人为错误导致的数据损坏中恢复。 可以通过时间点还原在同一服务器中创建一个新数据库,以表示损坏事件发生之前的数据状态。 大多数数据库的还原操作需要不到 12 小时的时间。 恢复非常大或十分活跃的数据库可能需要更长时间。 有关恢复时间的详细信息,请参阅数据库恢复时间

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

将异地复制与故障转移组进行比较

自动故障转移组简化了异地复制的部署和使用,并添加了其他功能,如下表中所述:

异地复制 故障转移组
自动故障转移
同时故障转移多个数据库
用户必须在故障转移后更新连接字符串
SQL 托管实例支持
可以与主服务器位于同一区域
多个副本
支持读取缩放

将数据库恢复到现有服务器

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

  • 用户可以选择等待数据中心中断结束,数据库重新联机。 这适用于可以容忍数据库脱机的应用程序。 例如无需一直处理的开发项目或免费试用版。 数据中心中断时,不知道中断会持续多久,因此该选项仅适用于暂时不需要数据库的情况。
  • 另一个选项是使用异地冗余数据库备份(异地还原)来还原任何 Azure 区域中任何服务器上的数据库。 异地还原使用异地冗余备份作为源,即使由于停电而无法访问数据库或数据中心,也依然能够使用它来恢复数据库。
  • 最后,如果你使用活动异地复制配置了异地辅助数据库或者为数据库配置了自动故障转移组,则可以快速从中断中恢复。 你可以使用手动或自动故障转移,具体取决于你选择的这些技术。 虽然故障转移本身只需几秒钟,但服务至少需要 1 小时才能激活它。 这是确保故障转移符合中断规模所必需的。 此外,由于异步复制的性质,故障转移可能导致少量数据丢失。

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

不同的恢复方法提供不同级别的 RPO 和 RTO。 可以选择特定的恢复方法,也可以使用各种方法的组合,以便实现应用程序的完全恢复。 下表比较了每个恢复选项的 RPO 和 RTO。 自动故障转移组简化了异地复制的部署和使用,并添加了其他功能,如下表所述。

恢复方法 RTO RPO
从异地复制的备份执行异地还原 12 小时 1 小时
自动故障转移组 1 小时 5 秒
手动数据库故障转移 30 秒 5 秒

备注

“手动数据库故障转移”是指使用计划外模式将单一数据库故障转移到其异地复制的辅助数据库。 有关自动故障转移 RTO 和 RPO 的详细信息,请参阅本文中前面的表。

如果应用程序符合以下任意条件,请使用自动故障转移组:

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

可以根据应用程序需求,选择结合使用数据库备份与活动异地复制。 若要探讨使用这些业务连续性功能为独立数据库和弹性池进行设计时的注意事项,请参阅设计用于云灾难恢复的应用程序弹性池灾难恢复策略

以下各节概述使用数据库备份或活动异地复制进行恢复的步骤。 若要了解包括计划需求在内的详细步骤、恢复后步骤,以及如何模拟中断以执行灾难恢复演练,请参阅在中断时恢复 SQL 数据库中的数据库

为中断做好准备

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

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

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

故障转移到异地复制的辅助数据库

如果你使用活动异地复制或自动故障转移组作为恢复机制,则可以配置自动故障转移策略,或使用手动计划外故障转移。 一旦启用,辅助数据库通过故障转移提升为新的主数据库,它可以记录新事务并响应查询 - 仅丢失极少尚未复制的数据。 有关设计故障转移过程的信息,请参阅设计用于云灾难恢复的应用程序

备注

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

执行异地还原

如果要将自动备份用于异地冗余存储(默认情况下已启用),则可以使用异地还原恢复数据库。 恢复通常在 12 小时内进行 - 最多丢失 1 小时的数据,具体取决于上次日志备份的执行和复制时间。 在恢复完成之前,数据库无法记录任何事务或响应任何查询。 请注意,异地还原仅将数据库还原到上一个可用时间点。

备注

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

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

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

  • 将客户端和客户端应用程序重定向到新服务器和还原的数据库。
  • 确保设置适当的服务器级 IP 防火墙规则,以便用户能够连接或使用数据库级防火墙,启用合适的规则。
  • 确保设置适当的登录名和 master 数据库级权限(或使用包含的用户)。
  • 视情况配置审核。
  • 视情况配置警报。

备注

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

在停机时间最短的情况下升级应用程序

有时,应用程序由于计划内维护(例如应用程序升级)而必须脱机。 管理应用程序升级介绍如何使用活动异地复制滚动升级云应用程序,将升级时的停机时间缩到最短,并在发生错误时提供恢复路径。

后续步骤

若要探讨为单一数据库和弹性池设计应用程序时的注意事项,请参阅设计用于云灾难恢复的应用程序弹性池灾难恢复策略