配置高可用性和灾难恢复

8 分钟

在 SQL Server 中配置灾难恢复和高可用性解决方案的主要部分在 SQL Server（在 Azure 虚拟机上运行）中保持不变。高可用性解决方案旨在保证提交的数据不会因故障而丢失，你的工作负荷不会受到维护操作的影响，并且数据库不会成为软件体系结构中的单一故障点。

大多数 Azure SQL 服务层级都提供一系列高可用性选项，从本地冗余模型到区域冗余模型，不一而足。

接下来，我们将探讨 Azure PaaS 产品/服务的灾难恢复和高可用性的具体解决方案。

连续备份

Azure SQL 数据库可确保对数据库进行定期备份和连续备份，然后将其复制到读取访问异地冗余存储 (RA-GRS)。

自动备份策略包含每周完整备份、每 12 到 24 小时进行一次的差异备份，以及每 5 到 10 分钟进行一次的事务日志备份。为了延长备份可用性（最长为 10 年），可以为单一数据库和共用数据库配置长期保留 (LTR)。

长期保留 (LTR)

Azure 提供了一项保留策略，你可以将其设置为超出通常限制，这对于需要长期保留的方案非常有用。可以设置最长 10 年的保留策略，默认情况下禁用此选项。

此图显示了如何在 Azure 门户上设置长期保留策略。选择数据库后，屏幕右侧会出现一个面板，你可以在其中更改默认设置。

有关长期保留的详细信息，请参阅长期保留 - Azure SQL 数据库和 Azure SQL 托管实例。

异地还原

默认情况下，SQL 数据库和 SQL 托管实例的备份是异地冗余的。这使你可以轻松地将数据库还原到另一地理区域，此功能对于不太严格的灾难恢复方案非常有用。

备份存储与常规数据库文件存储分开计费。但是，在预配 SQL 数据库存储时，会创建备份存储，其中为数据库选择了数据层的最大大小，且无需额外付费。

异地还原操作持续时间可能会受多个基础组件的影响，包括数据库的大小、还原操作涉及的事务日志数，以及目标区域要处理的同时还原请求的数量。

时间点还原 (PITR)

可以根据定义的保留期将数据库还原到特定的时间点，但只有在创建备份的服务器中还原数据库时，才支持 PITR。可以使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API 还原 SQL 数据库。

活动异地复制

提高 Azure SQL 数据库可用性的一种方法是使用活动异地复制。活动异地复制会在另一个区域创建一个辅助数据库副本，该副本以异步方式保持最新状态。

此副本是可读的，类似于 SQL Server 中的 AlwaysOn 可用性组。事实上，Azure 使用可用性组来维护此功能，因此一些术语是相似的。

活动异地复制允许客户在发生重大灾难期间以编程方式或手动将主数据库故障转移到次要区域，从而提供业务连续性。

注意

Azure SQL 托管实例不支持活动异地复制。你必须改为使用自动故障转移组，我们将在本单元的后面部分探讨这个主题。

此图显示 Azure SQL 数据库的活动异地复制。

异地复制关系中涉及的所有数据库都需要具有相同的服务层级。此外，为了防止由于写入工作负荷过重而导致复制性能问题，建议为次要副本配置与主要副本相同的计算大小。

Azure SQL 数据库副本页面的屏幕截图。

可以手动为 Azure SQL 数据库配置异地复制，方法是：访问数据库的边栏选项卡，在“数据管理”部分选择“副本”，然后选择“+ 创建副本”。

建立次要副本后，可以选择手动启动故障转移。在此过程中进行角色互换 - 次要副本承担主要副本的角色，而原始主要副本则成为次要副本。

跨订阅异地复制

在某些情况下，可能需要在与主数据库不同的订阅上配置次要副本。这就是跨订阅异地复制功能发挥作用的地方。

注意

跨订阅异地复制只能以编程方式使用。

若要详细了解配置跨订阅异地复制所需的步骤，请参阅跨订阅异地复制。

自动故障转移组

自动故障转移组是一项受 Azure SQL 数据库和 Azure SQL 托管实例支持的可用性功能。使用自动故障转移组，你可以管理将数据库复制到另一个区域的方式以及进行故障转移的方式。分配给自动故障转移组的名称在 *.database.windows.net 域中必须独一无二。

自动故障转移组可以包含多个数据库。主数据库和辅助数据库大小相同。

Azure SQL 数据库和 Azure SQL 托管实例的自动故障转移组的体系结构图。

自动故障转移组提供类似于 AG 的功能，称为侦听器，侦听器支持读写和只读活动。有两种不同类型的侦听器：一种用于读写流量，一种用于只读流量。在故障转移期间的后台中，DNS 会进行更新，这样客户端就能够指向抽象侦听器名称，而无需知道其他任何内容。包含读写副本的数据库服务器是主服务器，从主服务器接收事务的服务器是辅助服务器。

自动故障转移组有两种不同的策略。

策略类型	说明
自动	检测到故障时，系统默认自动触发故障转移。但是，你可以根据需要禁用自动故障转移。
只读	在故障转移期间，引擎默认禁用只读侦听器，以便在辅助数据库关闭时维持新主数据库的性能。但是，你可以更改此行为，以在故障转移后允许两种类型的流量。

故障转移是一个可以手动启动的过程，即使在启用了自动故障转移的情况下也是如此。但是，故障转移的类型可能会影响是否发生数据丢失。例如，如果强制执行计划外故障转移且辅助数据库尚未与主数据库完全同步，则可能会导致数据丢失。

GracePeriodWithDataLossHours 决定了 Azure 在启动故障转移之前的等待时间，默认值设置为一小时。如果恢复点目标 (RPO) 很严格并且不能丢失数据，则可将此值设置得更高。虽然这意味着 Azure 在启动故障转移之前需要等待更长的时间，但可能会减少数据丢失，因为为辅助数据库提供了更多时间与主数据库完全同步。

注意

辅助数据库是通过一个称为种子设定的过程自动创建的，该过程可能需要一些时间，具体取决于数据库大小。因此，考虑到网络速度之类的因素，提前计划非常重要。

若要详细了解 Azure SQL 数据库的高可用性和灾难恢复，请参阅 Azure SQL 数据库高可用性和灾难恢复清单。