故障转移组概述和最佳做法（Azure SQL 数据库）

适用于：Azure SQL 数据库

故障转移组功能可用于管理逻辑服务器中的一些或所有数据库到另一区域中逻辑服务器的复制和故障转移。 本文章概述了故障转移组功能，以及将其与 Azure SQL 数据库一起使用的最佳做法和建议。

若要开始使用该功能，请查看为 Azure SQL 数据库配置故障转移组。

概述

通过故障转移组功能，可以管理数据库到另一 Azure 区域的复制和故障转移。 可以选择将逻辑服务器中的所有用户数据库或用户数据库的子集复制到另一个逻辑服务器。 它是建立在现有活动异地复制功能基础之上的声明性抽象，旨在简化异地复制的数据库的大规模部署和管理。

有关异地故障转移 RPO 和 RTO 的信息，请参阅业务连续性概述。

端点重定向

故障转移组提供在异地故障转移期间保持不变的读写和只读侦听器终结点。 在发生异地故障转移后，你无需更改应用程序的连接字符串，因为连接会自动路由到当前的主服务器。 异地故障转移会将组中所有的辅助数据库切换为主角色。 异地故障转移完成后，会自动更新 DNS 记录，以便将终结点重定向到新的区域。

卸载只读工作负载

为了减少对主数据库的流量，还可以使用故障转移组中的辅助数据库来卸载只读工作负荷。 使用只读侦听器将只读流量定向到可读辅助数据库。

恢复应用程序

为了实现完整的业务连续性，添加区域数据库冗余只是解决方案的一部分。 在发生灾难性故障后，端对端地恢复应用程序（服务）需要恢复构成该服务的所有组件以及所有依赖服务。 这些组件的示例包括客户端软件（例如，使用自定义 JavaScript 的浏览器）、Web 前端、存储和 DNS。 所有组件必须能够弹性应对相同的故障，并在应用程序的恢复时间目标 (RTO) 值内变为可用，这一点非常关键。 因此，需要识别所有依赖服务，并了解它们提供的保证和功能。 然后，必须采取适当的步骤来确保在其所依赖的服务发生故障转移期间，您的服务能够正常运行。

故障转移策略

故障转移组支持两种故障转移策略：

• 由客户管理（推荐） - 当客户注意到故障转移组中的一个或多个数据库受到意外服务中断影响时，客户可以对该组执行故障转移。 使用命令行工具（如 PowerShell、Azure CLI 或 Rest API）时，由客户管理的故障转移策略值为 manual。
• 由 Azure 管理 - 如果发生了影响主区域的普遍服务中断，Azure 会启动其故障转移策略配置为“由 Azure 管理”的所有受影响故障转移组的故障转移。 不会为区域中的单个故障转移组或故障转移组的子集启动由 Azure 管理的故障转移。 使用命令行工具（如 PowerShell、Azure CLI 或 Rest API）时，Azure 托管的故障转移策略值为 automatic。

每个故障转移策略都有一组独特的用例，以及对故障转移范围和数据丢失的相应预期，如下表汇总：

由客户管理

在极少数情况下，内置的可用性或高可用性不足以缓解停机，故障转移组中数据库的离线持续时间可能会达到使用数据库的应用程序服务级别协议 (SLA) 无法接受的程度。 数据库可能由于仅影响少数数据库的本地化问题，也可能由于位于数据中心、可用性区域或区域级别的问题而离线。 在上述任何一种情况下，若要恢复业务连续性，可以启动强制故障转移。

强烈建议将故障转移策略设置为由客户管理，这样你就可以控制何时启动故障转移并还原业务连续性。 当你注意到意外中断影响了故障转移组中的一个或多个数据库时，就可以启动故障转移。

由 Azure 管理

通过 Azure 托管的故障转移策略，灾难恢复责任将委托给 Azure SQL 服务。 若要使 Azure SQL 服务启动强制故障转移，必须满足以下条件：

• 自然灾害事件、配置更改、软件错误或硬件组件故障引起了数据中心、可用性区域或区域级中断，并且该区域中的许多数据库都受到了影响。
• 宽限期已经到期。 由于验证中断的规模和缓解中断取决于人为操作，因此不能将宽限期设置为一小时以下。

满足这些条件时，Azure SQL 服务会为区域中所有已将故障转移策略设置为 Azure 托管的故障转移组启动强制故障转移。

仅在以下情况下将故障转移策略设置为由 Azure 管理：

• 你希望将灾难恢复职责委派给 Azure SQL 服务。
• 应用程序可以容忍你的数据库离线至少一小时或更长时间。
• 可以接受在宽限期过期后一段时间触发强制故障转移，因为强制故障转移的实际时间可能会有很大差异。
• 可以接受故障转移组中的所有数据库都进行故障转移，而无论其区域冗余配置或可用性状态如何。 尽管为区域冗余配置的数据库对区域故障具有抗性，可能不受停机影响，但如果它们是 Azure 托管故障转移策略中的故障转移组的一部分，仍然会进行故障转移。
• 可以接受在故障转移组中强制故障转移数据库，而不考虑应用程序对于其他 Azure 服务或组件的依赖关系，这可能会导致应用程序性能下降或无法使用。
• 可以接受发生未知数量的数据丢失，因为强制故障转移的确切时间无法控制，并且会忽略辅助数据库的同步状态。
• 故障转移组中的所有主要和辅助数据库以及任何异地复制关系都具有相同的服务层级、计算层级（预调配或无服务器）和计算大小（DTU 或 vCore）。 如果所有数据库的服务级别目标 (SLO) 不匹配，则故障转移策略最终将由 Azure SQL 服务从 Azure 托管更新到由客户管理。

Azure 触发故障转移时，故障转移 Azure SQL 故障转移组的操作名称条目会添加到 Azure Monitor 活动日志。 该条目包括“资源”下故障转移组的名称，启动的事件显示单个连字符 (-)，以指示故障转移是由 Azure 启动的。 也可以在 Azure 门户中新主服务器或实例的活动日志页上找到此信息。

术语和功能

• 故障转移组 (FOG)

  故障转移组是由故障转移组是由 Azure 中单个逻辑服务器管理的数据库的命名组，当主要区域的服务中断导致所有或部分主要数据库不可用时，该组数据库可作为一个单元故障转移到另一 Azure 区域。

  重要

  故障转移组的名称在 .database.chinacloudapi.cn 域中必须全局唯一。

• 服务器

  可将逻辑服务器上的部分或所有用户数据库放入故障转移组。 此外，服务器支持在同一台服务器上设置多个故障转移组。

• 主服务器

  托管故障转移组中主要数据库的逻辑服务器。

• 辅助服务器

  托管着故障转移组中的辅助数据库的逻辑服务器。 辅助数据库不能与主数据库位于相同的 Azure 区域。

• 故障转移（无数据丢失）

  辅助角色切换为主角色之前，故障转移会在主数据库与辅助数据库之间执行完整数据同步。 这可以保证数据不会丢失。 只有当主服务器可供访问时，才可能进行故障转移。 故障转移适用于以下场景：

  • 在数据丢失不可接受的情况下在生产环境中执行灾难恢复 (DR) 演练
  • 将工作负荷重新定位到不同的区域
  • 缓解服务中断（故障回复）后将工作负载恢复到主区域

• 强制故障转移（可能导致数据丢失）

  强制故障转移会立即将辅助角色切换为主角色，而不会等待从主角色传播最近的更改。 此操作可能导致潜在的数据丢失。 在服务中断期间，如果无法访问主服务器，会使用强制故障转移作为恢复方法。 缓解中断时，旧的主数据库将自动重新连接，并成为新的辅助数据库。 可以执行故障转移以进行故障回复，将副本恢复到其原来的主角色和辅助角色。

• 数据丢失宽限期

  由于数据是使用异步复制复制到辅助服务器的，因此使用 Azure 管理的故障转移策略对组进行强制故障转移可能会导致数据丢失。 可以自定义故障转移策略，以便反映应用程序对数据丢失的容错。 通过配置 GracePeriodWithDataLossHours，可以控制 Azure SQL 服务启动可能导致数据丢失的强制故障转移之前的等待时间。

• 将单一数据库添加到故障转移组

  可以将同一逻辑服务器上的多个单一数据库放入同一故障转移组。 如果将单一数据库添加到故障转移组，则它会在创建故障转移组时指定的辅助服务器上自动使用相同的版本和计算大小创建辅助数据库。 如果在辅助服务器中添加已具有辅助数据库的数据库，则该异地复制链接由组继承。 在不属于故障转移组的服务器中添加已有辅助数据库的数据库时，会在辅助服务器上创建新的辅助数据库。

  重要

  • 确保辅助逻辑服务器没有使用同一名称的数据库，除非它是现有的辅助数据库。
  • 如果数据库包含内存中 OLTP 对象，则主数据库和辅助异地副本数据库必须具有匹配的服务层级，因为内存中 OLTP 对象驻留在内存中。 如果异地副本数据库上的服务层级较低，可能会导致内存不足问题。 如果发生这种情况，异地副本可能无法恢复数据库，从而导致辅助数据库与异地辅助服务器上的内存中 OLTP 对象不可用。 这反过来又可能导致故障转移失败。 为避免这种情况，请确保异地辅助数据库的服务层级与主数据库的服务层级相匹配。 服务层级升级操作会针对不同的数据大小，并且可能需要一段时间才能完成。

• 将弹性池中的数据库添加到故障转移组

  可将一个弹性池内的所有或多个数据库放入同一故障转移组。 如果主数据库在弹性池中，将在具有相同名称的弹性池（辅助池）中自动创建辅助数据库。 必须确保辅助服务器包含名称完全相同的弹性池，并有足够的可用容量来托管将由故障转移组创建的辅助数据库。 如果在辅助池中已有辅助数据库的池中添加数据库，则该异地复制链接由组继承。 在不属于故障转移组的服务器中添加已有辅助数据库的数据库时，会在辅助池中创建新的辅助数据库。

• 故障转移组读写侦听器

  DNS CNAME 记录，指向当前主服务器。 此记录是在创建故障转移组时自动创建的，可让读写工作负载在故障转移发生后主服务器发生更改时，以透明方式重新连接到主服务器。 在服务器上创建故障转移组时，侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.database.chinacloudapi.cn。 故障转移后，会自动更新 DNS 记录以将侦听器重定向到新的主服务器。

• 故障转移组只读侦听器

  一个 DNS CNAME 记录，指向当前的辅助服务器。 此记录是在创建故障转移组时自动创建的，可让只读 SQL 工作负载在故障转移发生后辅助服务器发生更改时，以透明方式连接到辅助服务器。 在服务器上创建故障转移组时，侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.secondary.database.chinacloudapi.cn。 默认情况下，只读侦听器的故障转移是禁用的，因为这可以确保当辅助服务器离线时主服务器的性能不受影响。 但是，这也意味着在辅助服务器恢复前，只读会话将无法连接。 如果不能容忍只读会话停止服务，并且可以将主服务器用于只读和读写流量（代价是主服务器的性能可能降低），则可以通过配置 AllowReadOnlyFailoverToPrimary 属性为只读侦听器启用故障转移。 在这种情况下，如果辅助节点不可用，则会将只读流量自动重定向到主要节点。

  注意

  仅当已启用 Azure 托管故障转移策略，并触发强制故障转移时，该 AllowReadOnlyFailoverToPrimary 属性才有效。 在这种情况下，如果将该属性设置为 True，则新的主数据库将同时处理读写会话和只读会话。

• 多个故障转移组

  可为同一对服务器配置多个故障转移组以控制异地故障转移的范围。 每个组均独立进行故障转移。 如果您的应用程序采用每租户一个数据库模型，并且部署在多个区域且使用弹性池，您可以利用此功能在每个池中混合主数据库和辅助数据库。 通过这种方式，可以减少服务中断的影响，使其仅影响部分租户数据库。

故障转移组体系结构

Azure SQL 数据库的故障转移组可以包含一个或多个数据库，通常由同一应用程序使用。 必须在主服务器上配置一个故障转移组，将其连接到不同 Azure 区域中的辅助服务器。 故障转移组可以包含主服务器中的所有或部分数据库。 下图演示了使用故障转移组中的多个数据库的异地冗余云应用程序的典型配置：

设计具有业务连续性的服务时，请遵循本文中概述的一般指导原则和最佳实践。 配置故障转移组时，请确保辅助服务器上的身份验证和网络访问已设置为能够在异地故障转移之后（异地辅助服务器成为新的主服务器时）正常运行。 有关详细信息，请参阅 配置和管理 Azure SQL 数据库安全性以进行异地还原或故障转移。 有关详细信息，请参阅使用 Azure SQL 数据库设计全球可用的服务和 Azure SQL 数据库的异地还原。

使用配对区域

在主服务器和辅助服务器之间创建故障转移组时，请使用配对区域，因为与未配对区域相比，配对区域中的故障转移组性能更好。

根据安全部署实践，Azure SQL 数据库通常不会同时更新配对区域。 但是，无法预测将首先升级哪个区域，因此无法保证部署顺序。 有时，主服务器先升级，有时后升级。

如果为与 Azure 区域配对不一致的数据库配置了异地复制或故障转移组，请对主数据库和辅助数据库使用不同的维护时段安排。 例如，可以为辅助数据库选择工作日维护时段，为主数据库选择周末维护时段。

初始播种

将数据库或弹性池添加到故障转移组时，在数据复制开始之前，会有一个初始种子设定阶段。 初始种子设定阶段的操作耗时最长且开销最大。 初始种子设定完成后，数据将会同步，此后只会复制后续的数据更改。 完成初始种子设定所需的时间取决于数据大小、复制数据库的数量、主数据库上的负载，以及主数据库和辅助数据库之间的网络链接速度。 正常情况下，对于 SQL 数据库，可能的种子设定速度最高为每小时 500 GB。 种子设定是对所有数据库并行执行的。

故障转移组中的数据库数

故障转移组中的数据库数会直接影响故障转移和强制故障转移操作的持续时间。

• 在故障转移（也称为计划的故障转移）期间，我们会确保所有主数据库都与其辅助数据库完全同步，并达到就绪状态。 为避免控制平面过载，数据库会分批准备。 因此，强烈建议限制故障转移组中的数据库数。
• 在强制故障转移的情况下，由于未启动数据同步，因此准备阶段会加快。 但要实现更快且可预测的故障转移持续时间，建议将故障转移组中的数据库数保持在较小的数字。

使用多个故障转移组对多个数据库进行故障转移

可在不同区域的两个服务器（主服务器和辅助服务器）之间创建一个或多个故障转移组。 每组可包含一个或多个数据库，这些数据库是在所有或某些主数据库因主要区域中的服务中断而变得不可用时，作为单元恢复的。 创建故障转移组时，会创建与主数据库具有相同服务目标的异地辅助数据库。 如果将现有的异地复制关系添加到故障转移组，请确保使用与主服务器相同的服务层级和计算大小来配置异地辅助服务器。

使用读写侦听器（主服务器）

对于读写工作负荷，使用 <fog-name>.database.chinacloudapi.cn 作为连接字符串中的服务器名称。 连接会自动定向到主服务器。 此名称在故障转移后不会更改。 请注意，故障转移涉及更新 DNS 记录，以便仅在刷新客户端 DNS 缓存后，客户端连接才会重定向到新的主节点。 主要和辅助侦听器 DNS 记录的生存时间 (TTL) 为 30 秒。

使用只读侦听器（辅助服务器）

如果逻辑上隔离的只读工作负荷能够容忍数据延迟，则可以在异地辅助服务器上运行。 对于只读会话，使用 <fog-name>.secondary.database.chinacloudapi.cn 作为连接字符串中的服务器名称。 连接会自动定向到异地辅助服务器。 我们还建议你使用 ApplicationIntent=ReadOnly 在连接字符串中指示读取意向。

在高级、业务关键和超大规模服务层级中，SQL 数据库支持通过只读副本，使用连接字符串中的 ApplicationIntent=ReadOnly 参数卸载只读查询工作负荷。 如果配置了异地辅助服务器，则可以使用此功能连接到主位置或异地辅助位置中的只读副本：

若要连接到辅助位置中的只读副本，请使用 ApplicationIntent=ReadOnly 和 <fog-name>.secondary.database.chinacloudapi.cn。

故障转移后潜在的性能降低

典型的 Azure 应用程序使用多个 Azure 服务，并由多个组件构成。 组的故障转移仅根据 Azure SQL 数据库的状态触发。 主要区域中的其他 Azure 服务可能不受中断的影响，其组件可能仍在该区域中可用。 将主数据库切换为辅助 (DR) 区域后，依赖组件之间的延迟可能会增大。 为避免高延迟对应用程序性能造成影响，请确保对 DR 区域中的所有应用程序组件采取冗余配置，按照以下网络安全指南进行操作，并协调相关应用程序组件以及数据库的异地故障转移。

强制故障转移后潜在的数据丢失

如果主区域发生服务中断，则最近的事务可能尚未复制到异地辅助服务器，此时如果执行强制故障转移，则可能会丢失数据。

故障回复

如果为故障转移组配置了由 Azure 管理的故障转移策略，则会根据定义的宽限期在灾难情况下启动强制故障转移到异地辅助服务器。 故障回复到旧主服务器必须手动启动。

权限和限制

有关权限和限制的列表，请参阅配置故障转移组指南。

以编程方式管理故障转移组

也可以使用 Azure PowerShell、Azure CLI 和 REST API 以编程方式管理故障转移组。 有关详细信息，请查看为 Azure SQL 数据库配置故障转移组。

启用高可用性（区域冗余）

通过冗余实现可用性可通过防止区域中可用性区域的中断，进一步提高复原能力。

创建包含一个或多个数据库的故障转移组时，无论主数据库的高可用性设置如何，都无法为辅助数据库启用高可用性。

非超大规模数据库的区域冗余

通过故障转移组创建的辅助数据库在默认情况下不会启用高可用性。 创建故障转移组后，请在组中包含的数据库上启用高可用性。 如果首先创建活动异地复制，然后选择性地将数据库添加到故障转移组，则此行为也适用。

区域冗余与超大规模

通过故障转移组创建的辅助数据库将继承其各自主数据库的高可用性设置。 因此，如果主数据库启用了高可用性，则辅助数据库也会启用高可用性。 相反，如果主数据库未启用高可用性，则辅助数据库也不会启用。

对可用性区域的地区支持

如果主数据库上启用高可用性并且要添加的辅助数据库位于尚不支持可用性区域的区域中，工作流将失败并显示错误代码 45122：“创建或更新故障转移组操作已成功完成；但是，某些数据库无法添加到故障转移组或从故障转移组中移除“。 当前请求不支持预配区域冗余数据库/池。”若要解决此问题，请使用活动异地复制，其中你需在创建辅助数据库时启用或禁用高可用性。 然后，可以选择将这些数据库添加到故障转移组。

相关内容

• 有关示例脚本，请参阅：
  • 使用 PowerShell 为 Azure SQL 数据库配置活动异地复制
  • 使用 PowerShell 为 Azure SQL 数据库中的共用数据库配置活动异地复制
  • 使用 PowerShell 将 Azure SQL 数据库添加到故障转移组
• 有关业务连续性概述和应用场景，请参阅业务连续性概述
• 若要了解 Azure SQL 数据库的自动备份，请参阅 SQL 数据库自动备份。
• 若要了解如何使用自动备份进行恢复，请参阅从服务启动的备份中还原数据库。
• 若要了解新主服务器和数据库的身份验证要求，请参阅灾难恢复后的 SQL 数据库安全性。