为 Azure SQL 数据库配置故障转移组

适用于:Azure SQL 数据库

本文将指导你如何使用 Azure 门户、Azure PowerShell 和 Azure CLI 为 Azure SQL 数据库中的单一或共用数据库配置故障转移组

有关端到端脚本,请查看如何使用 Azure PowerShellAzure CLI 将单一数据库添加到故障转移组。

先决条件

考虑以下为单一数据库创建故障转移组的先决条件:

  • 辅助服务器的服务器登录名和防火墙设置必须与主服务器相匹配。

创建故障转移组

使用 Azure 门户创建故障转移组,并将单一数据库添加到其中。

  1. Azure 门户的左侧菜单中选择“Azure SQL”。 如果 Azure SQL 不在列表中,请选择“所有服务”,然后在搜索框中键入“Azure SQL”。 (可选)选择“Azure SQL”旁边的星号将其收藏并将其添加为左侧导航栏中的项。

  2. 选择要添加到故障转移组中的数据库。

  3. 服务器名称下选择服务器的名称以打开服务器的设置。

    Open server for single db

  4. 设置窗格下选择故障转移组,然后选择添加组以创建新的故障转移组。

    Add new failover group

  5. 在“故障转移组”页上输入或选择所需的值,然后选择“创建”。 创建新的辅助服务器,或选择现有的辅助服务器。 故障转移组中的辅助服务器必须与主服务器位于不同的区域。

    • 组中的数据库:选择要添加到故障转移组中的数据库。 将数据库添加到故障转移组的操作会自动启动异地复制过程。

    Add SQL Database to failover group

测试计划的故障转移

使用 Azure 门户或 PowerShell 测试故障转移组的故障转移,而不会丢失数据。

使用 Azure 门户测试故障转移组的故障转移。

  1. Azure 门户的左侧菜单中选择“Azure SQL”。 如果 Azure SQL 不在列表中,请选择“所有服务”,然后在搜索框中键入“Azure SQL”。 (可选)选择“Azure SQL”旁边的星号将其收藏并将其添加为左侧导航栏中的项。

  2. 选择要添加到故障转移组中的数据库。

    Open server for single db

  3. 在“设置”窗格下选择“故障转移组”,然后选择刚刚创建的故障转移组。

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  4. 查看哪个服务器是主服务器,哪个服务器是辅助服务器。

  5. 从任务窗格中选择“故障转移”,以对包含数据库的故障转移组进行故障转移。

  6. 在告知将会断开 TDS 会话连接的警告中选择“是”。

    Fail over your failover group containing your database

  7. 查看哪个服务器现在是主服务器,哪个服务器是辅助服务器。 如果故障转移成功,这两个服务器的角色应会交换。

  8. 再次选择“故障转移”,使服务器恢复其原始角色。

重要

如果需要删除辅助数据库,请先将其从故障转移组中移除,然后再将其删除。 如果在从故障转移组中移除辅助数据库之前将其删除,则可能会导致不可预知的行为。

有关端到端脚本,请查看如何使用 Azure PowerShellAzure CLI 将弹性池添加到故障转移组。

先决条件

考虑以下为共用数据库创建故障转移组的先决条件:

  • 辅助服务器的服务器登录名和防火墙设置必须与主服务器相匹配。

创建故障转移组

使用 Azure 门户或 PowerShell 为弹性池创建故障转移组。

使用 Azure 门户创建故障转移组,并将弹性池添加到其中。

  1. Azure 门户的左侧菜单中选择“Azure SQL”。 如果 Azure SQL 不在列表中,请选择“所有服务”,然后在搜索框中键入“Azure SQL”。 (可选)选择“Azure SQL”旁边的星号将其收藏并将其添加为左侧导航栏中的项。

  2. 选择要添加到故障转移组中的弹性池。

  3. 概述窗格上,选择服务器名称下的服务器名称以打开服务器的设置。

    Open server for elastic pool

  4. 设置窗格下选择故障转移组,然后选择添加组以创建新的故障转移组。

    Add new failover group

  5. 在“故障转移组”页上输入或选择所需的值,然后选择“创建”。 创建新的辅助服务器,或选择现有的辅助服务器。

  6. 选择组中的数据库,然后选择要添加到故障转移组中的弹性池。 如果辅助服务器上没有弹性池,则会出现一条警告,提示你在辅助服务器上创建弹性池。 选择该警告,然后选择确定以在辅助服务器上创建弹性池。

    Add elastic pool to failover group

  7. 使用选择以将弹性池设置应用到故障转移组,然后选择创建以创建故障转移组。 将弹性池添加到故障转移组的操作会自动启动异地复制过程。

测试计划的故障转移

使用 Azure 门户或 PowerShell 测试弹性池的故障转移,而不会丢失弹性池的数据。

将故障转移组故障转移到辅助服务器,然后使用 Azure 门户故障回复。

  1. Azure 门户的左侧菜单中选择“Azure SQL”。 如果 Azure SQL 不在列表中,请选择“所有服务”,然后在搜索框中键入“Azure SQL”。 (可选)选择“Azure SQL”旁边的星号将其收藏并将其添加为左侧导航栏中的项。

  2. 选择需要进行故障转移的弹性池。

  3. 概述窗格上,选择服务器名称下的服务器名称以打开服务器的设置。

    Screenshot of select server for elastic pool in the Azure portal.

  4. 设置下选择故障转移组,然后选择刚才创建的故障转移组。

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  5. 查看哪个服务器是主服务器,哪个服务器是辅助服务器。

  6. 在“任务”窗格中选择“故障转移”,以故障转移包含弹性池的故障转移组。

  7. 在告知将会断开 TDS 会话连接的警告中选择

    Fail over your failover group containing your database

  8. 查看哪个服务器是主服务器,哪个服务器是辅助服务器。 如果故障转移成功,这两个服务器的角色应会交换。

  9. 再次选择“故障转移”,将故障转移组故障回复到原始设置。

重要

如果需要删除辅助数据库,请先将其从故障转移组中移除,然后再将其删除。 如果在从故障转移组中移除辅助数据库之前将其删除,则可能会导致不可预知的行为。

使用专用链接,可以将逻辑服务器关联到虚拟网络和子网中的特定专用 IP 地址。

若要将专用链接用于故障转移组,请执行以下操作:

  1. 请确保主服务器和辅助服务器位于配对区域中。
  2. 在每个区域中创建虚拟网络和子网,以托管主服务器和辅助服务器的专用终结点,使其的 IP 地址空间不重叠。 例如,主虚拟网络地址范围 10.0.0.0/16 与辅助虚拟网络地址范围 10.0.0.1/16 重叠。 有关虚拟网络地址范围的详细信息,请参阅博客:设计 Azure 虚拟网络
  3. 创建主服务器的专用终结点和 Azure 专用 DNS 区域
  4. 同时为辅助服务器创建专用终结点,但这次选择重复使用为主服务器创建的同一专用 DNS 区域。
  5. 建立专用链接后,可以按照本文前面所述的步骤创建故障转移组。

定位侦听器终结点

配置故障转移组后,将应用程序的连接字符串更新为侦听器终结点。 这会使应用程序保持连接到故障转移组侦听器,而不是连接到主数据库或弹性池。 这样,就不必在每次数据库实体发生故障转移时都手动更新连接字符串,并且流量将路由到当前充当主实体的任何实体。

侦听器终结点采用 fog-name.database.chinacloudapi.cn 格式,查看故障转移组时,它会显示在 Azure 门户中:

Failover group connection string

在故障转移组中缩放数据库

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

特别建议按此顺序进行,以避免出现以下问题:较低 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 过程调用导致的延迟可能很明显,具体取决于调用时主数据库上尚未传输的事务日志大小。

更改次要区域

为了演示更改顺序,我们假设服务器 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 别名必须全局唯一,因此这将阻止你再次使用相同名称。 为最大程度地降低这种风险,请勿使用通用的故障转移组名称。

故障转移组和网络安全

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

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

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

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

注意

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

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

如果业务连续性计划要求使用故障转移组进行故障转移,则可以使用公共 IP 防火墙规则限制对 SQL 数据库的访问。 该配置可确保异地故障转移不会阻止来自前端组件的连接,并假定应用程序可以容忍前端与数据层之间的较长延迟。

若要支持故障转移组,请执行以下步骤:

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

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

重要

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

权限

通过 Azure 基于角色的访问控制 (Azure RBAC) 管理故障转移组的权限。

创建和管理故障转移组需要具有 Azure RBAC 写入访问权限。 SQL Server 参与者角色拥有管理故障转移组所需的全部权限。

下表列出了 Azure SQL 数据库的特定权限范围:

操作 权限 范围
创建故障转移组 Azure RBAC 写入访问权限 主服务器
辅助服务器
故障转移组内的所有数据库
更新故障转移组 Azure RBAC 写入访问权限 故障转移组
当前主服务器上的所有数据库
“对故障转移组进行故障转移” Azure RBAC 写入访问权限 新服务器的故障转移组

限制

注意以下限制:

  • 无法在同一 Azure 区域中的两个服务器之间创建故障转移组。
  • 故障转移组支持将组中所有数据库异地复制到另一个区域中唯一的辅助逻辑服务器。
  • 无法重命名故障转移组。 需要删除该组,并使用不同的名称重新创建它。
  • 故障转移组中的数据库不支持数据库重命名。 你需要暂时删除故障转移组才能重命名数据库,或者从故障转移组中删除数据库。
  • 删除单个数据库或共用数据库的故障转移组既不会停止复制,也不会删除复制的数据库。 如果要在删除单个数据库或共用数据库后将其重新添加到故障转移组,则需要手动停止异地复制并从辅助服务器中删除数据库。 尝试将数据库添加到故障转移组时,不执行上述两项操作可能会导致类似于 The operation cannot be performed due to multiple errors 的错误。
  • 故障转移组名称受命名限制的约束。

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

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

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

注意

可以使用 Azure Powershell 中的 -PartnerSubscriptionId 参数(从 Az.SQL 3.11.0 开始)跨订阅部署故障转移组。 若要了解详细信息,请查看以下示例

后续步骤

有关 Azure SQL 数据库高可用性选项的概述,请参阅异地复制故障转移组