使用自动故障转移组可以实现多个数据库的透明、协调式异地故障转移

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

通过自动故障转移组功能,可以管理服务器中一组数据库或托管实例中所有数据库到另一区域的复制和故障转移。 它是建立在现有活动异地复制功能基础之上的声明性抽象,旨在简化异地复制的数据库的大规模部署和管理。 可以手动启动故障转移,也可以基于用户定义的策略委托 Azure 服务进行故障转移。 使用后一种做法可在发生下述情况后自动恢复次要区域中的多个相关数据库:灾难性故障或其他导致主要区域中 SQL 数据库或 SQL 托管实例完全或部分丧失可用性的计划外事件。 一个故障转移组可以包含一个或多个数据库,通常由同一个应用程序使用。 此外,你还可以使用可读辅助数据库卸载只读查询工作负荷。

备注

自动故障转移组支持将组中所有的数据库异地复制到另一个区域中唯一的辅助服务器或实例。 如果需要为同一主要副本创建多个 Azure SQL 数据库异地辅助副本(在同一或不同区域),请使用活动异地复制

超大规模服务层当前不支持自动故障转移组。 对于超大规模数据库的地理故障转移,请使用活动异地复制

将自动故障转移组与自动故障转移策略配合使用时,影响组中一个或多个数据库的服务中断都会导致自动异地故障转移。 通常无法通过内置的高可用性基础结构自动缓解这些服务中断。 触发异地故障转移的示例包括 SQL 数据库租户通道或控制通道因计算节点上的 OS 内核内存泄漏关闭而导致的事件,或者一个或多个租户通道因例行停用硬件期间误切网线关闭而导致的事件。 有关详细信息,请参阅 SQL 数据库高可用性

此外,自动故障转移组提供在异地故障转移期间保持不变的读写和只读侦听器终结点。 无论使用手动故障转移激活还是自动故障转移激活,异地故障转移都会将组中所有的辅助数据库切换为主角色。 异地故障转移完成后,会自动更新 DNS 记录,以便将终结点重定向到新的区域。 有关异地故障转移 RPO 和 RTO 的信息,请参阅业务连续性概述

将自动故障转移组与自动故障转移策略配合使用时,影响服务器或托管实例中数据库的服务中断都会导致自动异地故障转移。

可使用以下方式管理自动故障转移组:

配置故障转移组时,请确保已设置辅助数据库上的身份验证和网络访问,以便在异地故障转移后正确运行,此时异地辅助数据库成为新的主要数据库。 有关详细信息,请参阅 SQL Database security after disaster recovery(灾难恢复后的 Azure SQL 数据库安全性)。

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

故障转移组的术语和功能

  • 故障转移组 (FOG)

    故障转移组是由一个服务器管理或位于一个托管实例中的一组指定数据库,当主要区域的服务中断导致所有或部分主要数据库不可用时,这组数据库可作为单元故障转移到另一区域。 为 SQL 托管实例创建故障转移组后,该组将包含该实例中的所有用户数据库,因此,只能在一个实例上配置一个故障转移组。

    重要

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

  • 服务器

    可将逻辑服务器上的部分或所有用户数据库放入故障转移组。 此外,服务器支持单个服务器上的多个故障转移组。

  • 主要节点

    托管故障转移组中的主数据库的服务器或托管实例。

  • 辅助节点

    托管故障转移组中的辅助数据库的服务器或托管实例。 辅助节点不能与主要节点位于相同的区域。

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

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

    重要

    确保辅助服务器没有使用同一名称的数据库,除非它是现有的辅助数据库。 在 SQL 托管实例的故障转移组中,将复制所有用户数据库。 无法选择复制故障转移组中的一部分用户数据库。

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

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

  • 初始种子设定

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

    对于 SQL 托管实例,在估算初始种子设定阶段的时间时,需考虑两个实例之间的 Express Route 链接的速度。 如果两个实例之间的链接速度比所需速度慢,则种子设定时间可能会受到明显影响。 可以根据所述种子设定速度、数据库数量、数据总大小和链接速度,来估算在数据复制开始之前初始种子设定阶段花费的时间。 例如,对于单个 100 GB 的数据库,如果链路每小时能够推送 84 GB 数据,并且没有其他数据库正在进行种子设定,则初始种子设定阶段需要花费大约 1.2 小时。 如果链路每小时只能传输 10 GB,则为 100 GB 数据库设定种子需要大约 10 小时。 如果有多个数据库要复制,则种子设定将会并行执行,在链接速度较慢的情况下,初始种子设定阶段可能需要相当长的时间,尤其是为所有数据库中的数据并行设定种子超过可用的链接带宽时。 如果两个实例之间的网络带宽受限制,而你要将多个托管实例添加到故障转移组,请考虑按顺序逐个地将多个托管实例添加到故障转移组。 如果两个托管实例之间的网关 SKU 的大小合适,并且公司网络带宽允许,则有可能实现高达 360 GB/小时的速度。

  • DNS 区域

    创建新 SQL 托管实例时自动生成的唯一 ID。 将为此实例预配一个多域 (SAN) 证书,以便对与同一 DNS 区域中的任何实例建立的客户端连接进行身份验证。 同一故障转移组中的两个托管实例必须共享 DNS 区域。

    备注

    为 SQL 数据库创建的故障转移组不需要或不使用 DNS 区域 ID。

  • 故障转移组读写侦听器

    DNS CNAME 记录,指向当前主要数据库。 此记录是创建故障转移组时自动创建的,可让读写工作负载在故障转移发生后主节点发生更改时,以透明方式重新连接到主数据库。 在服务器上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.database.chinacloudapi.cn。 在 SQL 托管实例上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.<zone_id>.database.chinacloudapi.cn

  • 故障转移组只读侦听器

    DNS CNAME 记录,指向当前辅助数据库。 此记录是创建故障转移组时自动创建的,可让只读 SQL 工作负载在故障转移发生后辅助节点发生更改时,以透明方式重新连接到辅助数据库。 在服务器上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.secondary.database.chinacloudapi.cn。 在 SQL 托管实例上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.secondary.<zone_id>.database.chinacloudapi.cn

  • 自动故障转移策略

    默认使用自动故障转移策略配置故障转移组。 检测到失败并且宽限期到期后,系统会触发异地故障转移。 系统必须确保,因影响范围太大等,内置高可用性基础结构无法缓解服务中断。 如果要从应用程序或手动控制异地故障转移工作流,可以关闭自动故障转移策略。

    备注

    由于验证中断规模及其缓解速度涉及到人工操作,因此不能将宽限期设置为一小时以下。 此限制适用于故障转移组中的所有数据库,不管其数据同步状态如何。

  • 只读故障转移策略

    默认禁用只读侦听器的故障转移功能。 这可确保在辅助数据库脱机时,主数据库的性能不会受到影响。 但是,这也意味辅助数据库恢复前,只读会话将无法连接。 如果不能容忍只读会话停机,但能容忍以主数据库的潜在性能降级为代价将主数据库用于只读和读写流量,则可以通过配置 AllowReadOnlyFailoverToPrimary 属性为只读侦听器启用故障转移。 在这种情况下,如果辅助节点不可用,则会将只读流量自动重定向到主要节点。

    备注

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

  • 计划的故障转移

    将辅助角色切换为主角色之前,计划内故障转移在主数据库与辅助数据库之间执行完整数据同步。 这可以保证数据不会丢失。 计划内故障转移用于以下场景:

    • 不可接受数据丢失时在生产环境中执行灾难恢复 (DR) 演练
    • 将数据库重新定位到不同的区域
    • 缓解服务中断(故障回复)后将数据库恢复到主要区域
  • 未计划的故障转移

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

  • 手动故障转移

    可随时手动启动异地故障转移,而不考虑自动故障转移配置。 在中断影响主要角色的情况下,如果未配置自动故障转移策略,则需要进行手动故障转移,以将辅助角色提升为主要角色。 可以启动强制(计划外)或友好的(计划内)故障转移。 只有在可以访问旧的主数据库时,才可以使用友好的故障转移,并且可以用来将主数据库重新定位到次要区域,而不会丢失数据。 故障转移完成后,会自动更新 DNS 记录,以确保与新的主要副本建立连接。

  • 数据丢失宽限期

    由于辅助数据库是使用异步复制进行同步的,因此自动异地故障转移可能会导致数据丢失。 可以自定义自动故障转移策略,以便反映应用程序对数据丢失的容错。 通过配置 GracePeriodWithDataLossHours,可以控制系统启动可能导致数据丢失的强制故障转移之前的等待时间。

  • 多个故障转移组

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

    备注

    SQL 托管实例不支持多个故障转移组。

权限

通过 Azure 基于角色的访问控制 (Azure RBAC) 管理故障转移组的权限。 SQL Server 参与者角色拥有管理故障转移组所需的全部权限。

创建故障转移组

若要创建某个故障转移组,需要对主服务器和辅助服务器,以及该故障转移组中的所有数据库拥有 Azure RBAC 写入访问权限。 对于 SQL 托管实例,需要对主要和辅助 SQL 托管实例拥有 Azure RBAC 写入访问权限,但对单个数据库的权限无关紧要,因为无法在故障转移组中添加或删除单个 SQL 托管实例数据库。

更新故障转移组

若要更新某个故障转移组,需要对该故障转移组,以及当前主服务器或托管实例上的所有数据库拥有 Azure RBAC 写入访问权限。

对故障转移组进行故障转移

若要对某个故障转移组进行故障转移,需要对新的主服务器或托管实例上的故障转移组拥有 Azure RBAC 写入访问权限。

SQL 数据库的故障转移组最佳做法

自动故障转移组必须在主服务器上进行配置,需将其连接到不同 Azure 区域中的辅助服务器。 组可以包含这些服务器中的所有或部分数据库。 下图演示了使用多个数据库和自动故障转移组的异地冗余云应用程序的典型配置。

此图演示了使用多个数据库和自动故障转移组的异地冗余云应用程序的典型配置。

备注

有关将 SQL 数据库中的数据库添加到故障转移组的详细分步教程,请参阅将 SQL 数据库添加到故障转移组

在设计具有业务连续性的服务时,请遵循以下一般准则:

使用一个或多个故障转移组来管理多个数据库的故障转移

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

使用读写侦听器连接到主数据库

对于读写工作负载,使用 <fog-name>.database.chinacloudapi.cn 作为连接字符串中的服务器名称。 连接将自动定向到主数据库。 此名称在故障转移后不会更改。 请注意,故障转移涉及更新 DNS 记录,以便仅在刷新客户端 DNS 缓存后,客户端连接才会重定向到新的主数据库。

使用只读侦听器连接到异地辅助数据库

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

备注

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

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

异地故障转移后性能可能下降

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

异地故障转移后潜在的数据丢失

如果主要区域发生服务中断,最新事务可能无法复制到异地辅助区域。 如果配置了自动故障转移策略,系统会等待你在 GracePeriodWithDataLossHours 中指定的时间,然后才启动自动异地故障转移。 默认值为 1 小时。 这更倾向于数据库可用性,而不是无数据丢失。 将 GracePeriodWithDataLossHours 设置为更大的数字(例如 24 小时)或禁用自动异地故障转移可降低数据丢失的可能性,但会牺牲数据库可用性。

重要

DTU 少于或等于 800、vCore 少于或等于 8、数据库超过 250 个的弹性数据库池可能会遇到更长的计划异地故障转移和性能下降等问题。 这些问题更可能在写密集型工作负载下发生,例如,异地副本广泛分隔于各个地理位置,或者每个数据库使用多个辅助异地副本。 这些问题的其中一个表现如下:异地复制的延迟逐步增大,可能导致服务中断期间更大量的数据丢失。 这种滞后可以使用 sys.dm_geo_replication_link_status 进行监视。 如果出现这些问题,则缓解措施包括纵向扩展池以拥有更多 DTU 或 vCore,或减少池中异地复制的数据库的数量。

更改故障转移组的辅助区域

为了演示更改顺序,我们假设服务器 A 是主服务器,服务器 B 是现有的辅助服务器,服务器 C 是第三个区域中的新辅助服务器。 若要进行转换,请执行以下步骤:

  1. 使用活动异地复制,在服务器 C 中为服务器 A 上的每个数据库创建额外的辅助数据库。 服务器 A 上的每个数据库具有两个辅助数据库,其中一个位于服务器 B 上,另一个位于服务器 C 上。这可以保证主数据库在转换过程中仍受保护。
  2. 删除故障转移组。 此时,使用故障转移组终结点的登录尝试将失败。
  3. 在服务器 A 和 C 之间重新创建同名的故障转移组。
  4. 将服务器 A 上的所有主数据库添加到新的故障转移组。 此时,登录尝试将不再失败。
  5. 删除服务器 B。将自动删除 B 上的所有数据库。

更改故障转移组的主要区域

为了演示更改顺序,我们假设服务器 A 是主服务器,服务器 B 是现有的辅助服务器,服务器 C 是第三个区域中的新主服务器。 若要进行转换,请执行以下步骤:

  1. 执行计划的异地故障转移以将主服务器切换到 B。服务器 A 将成为新的辅助服务器。 故障转移可能会导致几分钟的停机。 实际时间取决于故障转移组的大小。
  2. 使用活动异地复制,在服务器 C 中为服务器 B 上的每个数据库创建额外的辅助数据库。 服务器 B 上的每个数据库具有两个辅助数据库,其中一个位于服务器 A 上,另一个位于服务器 C 上。这可以保证主数据库在转换过程中仍受保护。
  3. 删除故障转移组。 此时,使用故障转移组终结点的登录尝试将失败。
  4. 在服务器 B 和 C 之间重新创建同名的故障转移组。
  5. 将服务器 B 上的所有主数据库添加到新的故障转移组。 此时,登录尝试将不再失败。
  6. 执行故障转移组的计划异地故障转移以切换 B 和 C。现在服务器 C 将成为主服务器,B 将成为辅助服务器。 服务器 A 上的所有辅助数据库将自动链接到 C 上的主数据库。如步骤 1 中所述,故障转移可能会导致几分钟的停机。
  7. 删除服务器 A。将自动删除 A 上的所有数据库。

重要

删除故障转移组时,也会删除侦听器终结点的 DNS 记录。 此时,其他人有可能创建同名的故障转移组或服务器 DNS 别名。 由于故障转移组名称和 DNS 别名必须全局唯一,因此这将阻止你再次使用相同名称。 为最大程度地降低这种风险,请勿使用通用的故障转移组名称。

SQL 托管实例的故障转移组最佳做法

自动故障转移组必须在主要实例上进行配置,需将其连接到不同 Azure 区域中的辅助实例。 实例中的所有用户数据库将复制到辅助实例。 不会复制 master 和 msdb 这样的系统数据库。

下图演示了使用托管实例和自动故障转移组的异地冗余云应用程序的典型配置。

自动故障转移示意图

备注

有关添加 SQL 托管实例以使用故障转移组的详细分步教程,请参阅将托管实例添加到故障转移组

如果应用程序使用 SQL 托管实例作为数据层,进行业务连续性设计时,请遵循以下一般准则:

创建异地辅助托管实例

若要确保故障转移后与主要 SQL 托管实例的连接不中断,主要实例和辅助实例必须位于同一 DNS 区域。 这将确保可以使用同一多域 (SAN) 证书来验证客户端与故障转移组中两个实例中任一实例的连接。 准备好将应用程序部署到生产环境后,在不同的区域中创建一个辅助 SQL 托管实例,并确保它与主要 SQL 托管实例共享 DNS 区域。 可以通过在创建期间指定可选参数来实现。 如果使用的是 PowerShell 或 REST API,则可选参数的名称为 DNSZonePartner。 Azure 门户中相应可选字段的名称是主要托管实例。

重要

在子网中创建的第一个托管实例确定同一子网中所有后续实例的 DNS 区域。 这意味着,同一子网中的两个实例不能属于不同的 DNS 区域。

有关在主要实例所在的 DNS 区域中创建辅助 SQL 托管实例的详细信息,请参阅创建辅助托管实例

使用配对区域

出于性能方面的考虑,将两个托管实例部署到配对区域。 与非配对区域相比,配对区域中的 SQL 托管实例故障转移组具有更好的性能。

在两个托管实例之间启用异地复制流量

由于每个托管实例隔离在其自身的 VNet 中,因此,必须允许这些 VNet 之间的双向流量。 请参阅 Azure VPN 网关

在不同订阅的托管实例之间创建故障转移组

可以在两个不同订阅中的 SQL 托管实例之间创建故障转移组,前提是订阅与相同的 Azure Active Directory 租户关联。 使用 PowerShell API 时,可以通过为辅助 SQL 托管实例指定 PartnerSubscriptionId 参数来执行此操作。 使用 REST API 时,properties.managedInstancePairs 参数中包含的每个实例 ID 都可以具有自己的订阅 ID。

重要

Azure 门户不支持创建跨不同订阅的故障转移组。 此外,对于跨不同订阅和/或资源组的现有故障转移组,无法通过门户从主要 SQL 托管实例手动启动故障转移。 改为从异地辅助实例启动它。

管理到异地辅助实例的异地故障转移

故障转移组将管理主要托管实例上所有数据库的异地故障转移。 创建某个组后,实例中的每个数据库将自动异地复制到异地辅助实例。 无法使用故障转移组针对一部分数据库启动部分故障转移。

重要

如果从主要托管实例中删除了某个数据库,该数据库也会在异地辅助托管实例上自动删除。

使用读写侦听器连接到主要托管实例

对于读写工作负载,使用 <fog-name>.zone_id.database.chinacloudapi.cn 作为服务器名称。 连接将自动定向到主数据库。 此名称在故障转移后不会更改。 异地故障转移涉及更新 DNS 记录,以便仅在刷新客户端 DNS 缓存后,客户端连接才会重定向到新的主数据库。 由于辅助实例与主要实例共享 DNS 区域,客户端应用程序可以使用相同的服务器端 SAN 证书重新连接到辅助实例。

使用只读侦听器连接到异地辅助托管实例

如果逻辑上隔离的只读工作负载可以容忍数据延迟,则可以在异地辅助数据库上运行。 若要直接连接到异地辅助数据库,请使用 <fog-name>.secondary.<zone_id>.database.chinacloudapi.cn 作为服务器名称。

备注

在业务关键层中,SQL 托管实例支持使用只读副本通过连接字符串中的 ApplicationIntent=ReadOnly 参数卸载只读查询工作负载。 如果配置了异地复制的辅助节点,则可以使用此功能连接到主要位置或异地复制位置中的只读副本。

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

故障转移到异地辅助托管实例后潜在的性能下降

典型的 Azure 应用程序使用多个 Azure 服务,并由多个组件构成。 是否对故障转移组进行自动异地故障转移仅根据 Azure SQL 组件的状态来决定。 主要区域中的其他 Azure 服务可能不受中断的影响,其组件可能仍在该区域中可用。 将主数据库切换到次要区域后,依赖组件之间的延迟可能会增大。 若要避免较高延迟对应用程序性能造成影响,请确保对次要区域中的所有应用程序组件采用冗余配置,并对应用程序组件和数据库进行故障转移。 在配置时,请遵循网络安全准则,以确保与次要区域中的数据库连接。

故障转移到异地辅助托管实例后潜在的数据丢失

如果主要区域发生服务中断,最新事务可能无法复制到异地辅助区域。 如果配置了自动故障转移策略,则根据了解,在没有丢失数据的情况下会触发异地故障转移。 否则,故障转移将延迟到使用 GracePeriodWithDataLossHours 指定的时间段。 如果配置了自动故障转移策略,请做好数据丢失的准备。 一般情况下,在中断期间 Azure 倾向于可用性。 将 GracePeriodWithDataLossHours 设置为更大的数字(例如 24 小时)或禁用自动异地故障转移可降低数据丢失的可能性,但会牺牲数据库可用性。

启动故障转移后,读写侦听器的 DNS 更新会立即发生。 此操作不会导致数据丢失。 但是,在正常情况下,切换数据库角色的过程可能需要 5 分钟时间。 在完成之前,新主要实例中的某些数据库仍是只读的。 如果使用 PowerShell 发起故障转移,则切换主要副本角色的操作是同步的。 如果使用 Azure 门户启动故障转移,UI 将指示完成状态。 如果使用 REST API 启动故障转移,可以使用标准 Azure 资源管理器的轮询机制来监视完成状态。

重要

缓解引发异地故障转移的服务中断后,使用手动计划故障转移将主数据库移回初始位置。

更改托管实例故障转移组的辅助区域

假设实例 A 是主实例,实例 B 是现有的辅助实例,实例 C 是第三个区域中的新辅助实例。 若要进行转换,请执行以下步骤:

  1. 在同一个 DNS 区域中创建大小与 A 相同的实例 C。
  2. 删除实例 A 与 B 之间的故障转移组。此时,登录将会失败,因为故障转移组侦听器的 SQL 别名已删除,因此网关无法识别故障转移组名称。 辅助数据库将从主实例断开连接,并成为读写数据库。
  3. 在实例 A 与 C 之间创建同名的故障转移组。按照包含 SQL 托管实例的故障转移组教程中的说明操作。 这是一个与数据大小相关的操作,实例 A 中的所有数据库都已设定种子并同步后,此操作将会完成。
  4. 如果不需要实例 B,请将其删除,以免产生不必要的费用。

备注

完成步骤 2 到 3 后,如果实例 A 发生灾难性故障,其中的数据库将仍不受保护。

更改托管实例故障转移组的主要区域

假设实例 A 是主实例,实例 B 是现有的辅助实例,实例 C 是第三个区域中的新主实例。 若要进行转换,请执行以下步骤:

  1. 在同一个 DNS 区域中创建大小与 B 相同的实例 C。
  2. 连接到实例 B,并手动故障转移以将主实例切换到 B。实例 A 将自动成为新的辅助实例。
  3. 删除实例 A 和 B 之间的故障转移组。此时,使用故障转移组终结点的登录尝试将失败。 A 上的辅助数据库将与主数据库断开连接,并成为读写数据库。
  4. 在实例 A 与 C 之间创建同名的故障转移组。按照包含托管实例的故障转移组教程中的说明操作。 这是一个与数据大小相关的操作,实例 A 中的所有数据库都已设定种子并同步后,此操作将会完成。 此时,登录尝试将不再失败。
  5. 如果不需要实例 A,请将其删除,以免产生不必要的费用。

注意

完成步骤 3 到 4 后,如果实例 A 发生灾难性故障,其中的数据库将仍不受保护。

重要

删除故障转移组时,也会删除侦听器终结点的 DNS 记录。 此时,其他人有可能创建同名的故障转移组。 由于故障转移组名称必须全局唯一,因此这将阻止你再次使用相同名称。 为最大程度地降低这种风险,请勿使用通用的故障转移组名称。

启用依赖于系统数据库中的对象的方案

系统数据库不会复制到故障转移组中的辅助实例。 若要启用依赖于系统数据库中的对象的方案,请确保在辅助实例上创建相同的对象并让辅助实例与主实例保持同步。

例如,如果你计划在辅助实例上使用相同的登录名,请确保使用相同的 SID 创建它们。

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

在主实例和辅助实例之间同步实例属性和保留策略

故障转移组中的实例保持独立的 Azure 资源,对主实例配置所做的任何更改都不会自动复制到辅助实例。 确保同时在主要和辅助实例上执行所有相关更改。 例如,如果在主实例上更改备份存储冗余或长期备份保留策略,请确保在辅助实例上也进行更改。

故障转移组和网络安全

对于某些应用程序,安全规则要求只允许特定组件(如 VM、Web 服务等)通过网络访问数据层。此要求对业务连续性设计和故障转移组的使用提出了一些挑战。 在实施此类受限访问时,请考虑以下选项。

使用故障转移组和虚拟网络服务终结点

如果使用虚拟网络服务终结点和规则来限制对 SQL 数据库或 SQL 托管实例中的数据库的访问,请注意每个虚拟网络服务终结点仅适用于一个 Azure 区域。 终结点不允许其他区域接受来自该子网的通信。 因此,只有部署在同一区域中的客户端应用程序才能连接到主数据库。 因为异地故障转移会导致 SQL 数据库客户端会话重新路由到不同(次要)区域中的服务器,所以源自该区域之外的客户端的这些会话将失败。 因此,如果参与的服务器或实例包含在虚拟网络规则中,则无法启用自动故障转移策略。 若要支持手动故障转移,请执行以下步骤:

  1. 在次要区域中预配应用程序前端组件(Web 服务、虚拟机等)的冗余副本。
  2. 为主服务器和辅助服务器分别配置虚拟网络规则
  3. 使用流量管理器配置启用前端故障转移
  4. 检测到服务中断时启动手动异地故障转移。 此选项针对需要在前端和数据层之间保持一致延迟的应用程序进行了优化,并支持在前端和/或数据层受到服务中断的影响时进行恢复。

备注

如果使用 只读侦听器 对只读工作负荷进行负载均衡,请确保在次要区域中的 VM 或其他资源上执行此工作负荷,以便它可以连接到辅助数据库。

使用故障转移组和防火墙规则

如果业务连续性计划要求使用自动故障转移组进行故障转移,则可以使用公共 IP 防火墙规则限制对 SQL 数据库中的数据库的访问。 若要支持自动故障转移,请执行以下步骤:

  1. 创建公共 IP
  2. 创建公共负载均衡器并为其分配公共 IP。
  3. 为前端组件创建虚拟网络和虚拟机
  4. 创建网络安全组并配置入站连接。
  5. 使用 Sql.<Region> 服务标记确保出站连接向某一区域中的 Azure SQL 数据库开放。
  6. 创建 SQL 数据库防火墙规则,以允许来自步骤 1 中创建的公共 IP 地址的入站流量。

有关如何配置出站访问以及在防火墙规则中使用哪个 IP 的详细信息,请参阅负载均衡器出站连接

上述配置将确保自动异地故障转移不会阻止来自前端组件的连接,并假定应用程序可以容忍前端与数据层之间的较长延迟。

重要

若要保证区域服务中断期间的业务连续性,则必须确保前端组件和数据库的地理冗余。

在托管实例虚拟网络之间启用异地复制

在两个不同区域中的主要和辅助 SQL 托管实例之间设置故障转移组时,将使用独立的虚拟网络来隔离每个实例。 若要允许这些 VNet 之间的复制流量,请确保满足以下先决条件:

  • SQL 托管实例的两个实例需位于不同的 Azure 区域中。

  • SQL 托管实例的这两个实例需位于相同的服务层级,并且具有相同的存储大小。

  • SQL 托管实例的辅助实例必须是空的(不包含任何用户数据库)。

  • 需要通过 VPN 网关Express Route 来连接 SQL 托管实例的实例使用的虚拟网络。 当两个虚拟网络通过本地网络连接时,请确保没有任何防火墙规则阻止端口 5022 和 11000-11999。 支持全局 VNet 对等互连,但有如下说明所述的限制。

    重要

    2020 年 9 月 22 日,我们宣布支持为新建的虚拟群集建立全局虚拟网络对等互连。 这意味着,自公告日期之后在空子网中创建的 SQL 托管实例以及在这些子网中随后创建的所有托管实例,都支持全局虚拟网络对等互连。 对于所有其他 SQL 托管实例,由于全局虚拟网络对等互连的约束,对等互连支持仅限于同一区域中的网络。 有关更多详细信息,另请参阅 Azure 虚拟网络常见问题解答一文的相关部分。

  • 两个 SQL 托管实例 VNet 的 IP 地址不能重叠。

  • 需要设置网络安全组 (NSG),使端口 5022 和端口范围 11000~12000 保持打开,以便能够从其他托管实例的子网建立入站和出站连接。 目的是允许实例之间的复制流量。

    重要

    NSG 安全规则配置不当会导致数据库种子设定操作停滞。

  • 辅助 SQL 托管实例上已配置正确的 DNS 区域 ID。 DNS 区域是 SQL 托管实例和基础虚拟群集的属性,其 ID 包含在主机名地址中。 在每个 VNet 中创建第一个 SQL 托管实例时,将生成随机字符串形式的区域 ID。同一个 ID 将分配到同一子网中的所有其他实例。 分配后,无法修改 DNS 区域。 同一故障转移组中包含的 SQL 托管实例必须共享 DNS 区域。 为此,在创建辅助实例时,可以传递主要实例的区域 ID 作为 DnsZonePartner 参数的值。

    备注

    有关使用 SQL 托管实例配置故障转移组的详细教程,请参阅将 SQL 托管实例添加到故障转移组

缩放主数据库

无需断开任何异地辅助数据库,即可将主数据库纵向扩展或纵向缩减到不同的计算大小(在相同服务层级中)。 在纵向扩展时,建议你首先扩展异地辅助数据库,然后再扩展主数据库。 纵向缩减时,则按相反顺序进行:先缩减主数据库,再缩减辅助数据库。 将数据库缩放到不同服务层级时,将强制执行此建议操作。

特别建议按此顺序进行,以避免出现以下问题:较低 SKU 的异地辅助数据库过载,并且必须在升级或降级过程中重新设定种子。 此外,可以通过将主数据库设为只读来避免问题,代价是针对主数据库的所有读写工作负荷会受到影响。

备注

如果在故障转移组配置过程中创建了异地辅助数据库,则不建议对其进行缩减。 这是为了确保进行异地故障转移后,数据层有足够的容量来处理常规工作负载。

防止关键数据丢失

由于广域网的延迟时间较长,异地复制使用了异步复制机制。 如果主数据库发生故障,异步复制会导致数据丢失不可避免。 为了防止这些关键事务数据丢失,应用程序开发人员可以在提交事务后立即调用 sp_wait_for_database_copy_sync 存储过程。 调用 sp_wait_for_database_copy_sync 会阻止调用线程,直到最后提交的事务已传输并强制执行到辅助数据库的事务日志中。 但是,它不会等待传输的事务在辅助数据库进行重播(恢复)。 sp_wait_for_database_copy_sync 范围限定为特定异地复制链接。 对主数据库具有连接权限的任何用户都可以调用此过程。

备注

sp_wait_for_database_copy_sync 防止特定事务异地故障转移后数据丢失,但不保证完全同步进行读取访问。 sp_wait_for_database_copy_sync 过程调用导致的延迟可能很明显,具体取决于调用时主数据库上尚未传输的事务日志大小。

故障转移组和时间点还原

有关将时间点还原与故障转移组配合使用的信息,请参阅时间点恢复 (PITR)

故障转移组的限制

注意以下限制:

  • 无法在同一 Azure 区域中的两个服务器或实例之间创建故障转移组。
  • 无法重命名故障转移组。 需要删除该组,并使用不同的名称重新创建它。
  • 故障转移组中的数据库不支持数据库重命名。 你需要暂时删除故障转移组才能重命名数据库,或者从故障转移组中删除数据库。
  • 系统数据库不会复制到故障转移组中的辅助实例。 因此,依赖于系统数据库中对象的方案要求在辅助实例上手动创建对象,并在对主实例进行更改后手动保持同步。 唯一的例外是 SQL 托管实例的服务主密钥 (SMK),它在创建故障转移组期间自动复制到辅助实例。 但是,在主实例上进行的任何后续 SMK 更改都不会复制到辅助实例。

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

如上所述,也可以使用 Azure PowerShell、Azure CLI 和 REST API 以编程方式管理自动故障转移组。 下表描述了可用的命令集。 活动异地复制包括一组用于管理的 Azure 资源管理器 API,其中包括 Azure SQL 数据库 REST APIAzure PowerShell cmdlet。 这些 API 需要使用资源组,并支持 Azure 基于角色的访问控制 (Azure RBAC)。 有关如何实现访问角色的详细信息,请参阅 Azure 基于角色的访问控制 (Azure RBAC)

管理 SQL 数据库异地故障转移

Cmdlet 说明
New-AzSqlDatabaseFailoverGroup 此命令会创建故障转移组,并将其同时注册到主服务器和辅助服务器
Remove-AzSqlDatabaseFailoverGroup 从服务器中删除故障转移组
Get-AzSqlDatabaseFailoverGroup 检索故障转移组的配置
Set-AzSqlDatabaseFailoverGroup 修改故障转移组的配置
Switch-AzSqlDatabaseFailoverGroup 触发故障转移组到辅助服务器的故障转移
Add-AzSqlDatabaseToFailoverGroup 将一个或更多个数据库添加到故障转移组

管理 SQL 托管实例异地故障转移

Cmdlet 说明
New-AzSqlDatabaseInstanceFailoverGroup 此命令会创建故障转移组,并将其同时注册到主实例和辅助实例
Set-AzSqlDatabaseInstanceFailoverGroup 修改故障转移组的配置
Get-AzSqlDatabaseInstanceFailoverGroup 检索故障转移组的配置
Switch-AzSqlDatabaseInstanceFailoverGroup 触发故障转移组到辅助实例的故障转移
Remove-AzSqlDatabaseInstanceFailoverGroup 删除故障转移组

后续步骤