故障转移组概述和最佳做法（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。

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

故障转移策略	故障转移范围	用例	可能丢失数据
由客户管理 （推荐使用）	故障转移组	故障转移组中的一个或多个数据库受中断的影响而离线。 可以选择故障转移。	是
Azure 托管	区域中的所有故障转移组	数据中心、可用性区域或区域中发生大范围中断，导致数据库离线，Microsoft Azure SQL 服务团队决定触发强制故障转移。 仅当想要将灾难恢复责任委托给 Azure 并且应用程序能够容忍至少一小时或以上的 RTO（停机时间）时，才使用此选项。	是

由客户管理

在极少数情况下，内置的可用性或高可用性不足以缓解停机，故障转移组中数据库的离线持续时间可能会达到使用数据库的应用程序服务级别协议 (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 中的逻辑服务器管理的一组命名的数据库，当主要区域的服务中断导致所有或部分主数据库不可用时，该组数据库可作为一个单元故障转移到另一区域。

  重要

  故障转移组的名称在 .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 区域中的辅助服务器。 故障转移组可以包含主服务器中的所有或部分数据库。 下图演示了使用故障转移组中的多个数据库的异地冗余云应用程序的典型配置：

设计具有业务连续性的服务时，请遵循本文中概述的一般指导原则和最佳实践。 配置故障转移组时，请确保已设置辅助数据库上的身份验证和网络访问，以便在异地故障转移后正确运行，此时异地辅助数据库成为新的主要数据库。 有关详细信息，请参阅 SQL Database security after disaster recovery（灾难恢复后的 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 以编程方式管理故障转移组。 有关详细信息，请参阅配置故障转移组。

相关内容

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