对 Always On 高可用性组进行强制手动切换（SQL Server）

2025-10-06

本文介绍如何使用 SQL Server Management Studio、Transact-SQL 或 SQL Server 中的 PowerShell 在 AlwaysOn 可用性组上执行强制故障转移（可能丢失数据）。强制故障转移是一种手动故障转移形式，专门用于灾难恢复，当< c0>计划的手动故障转移无法进行的情况下。如果您强制故障转移到某一未同步的辅助副本，则可能会丢失一些数据。因此，我们强烈建议仅在您必须立即向可用性组还原服务且愿意承受数据丢失风险的情况下，才强制进行故障转移。

执行强制故障转移之后，可用性组故障转移到的故障转移目标将变成新的主副本。剩余辅助副本中的辅助数据库将会挂起并且必须手动恢复。当以前的主副本可用时，它将转换为辅助角色，导致以前的主数据库成为辅助数据库并转换为 SUSPENDED 状态。在恢复某一给定的辅助数据库之前，您可能能够从其还原丢失的数据。但请注意，在其任何辅助数据库被挂起时，事务日志截断在给定的主数据库上被延迟。

重要

在恢复辅助数据库之前，不会发生与主数据库的数据同步。有关恢复辅助数据库的信息，请参阅本文后面部分的跟进：强制故障转移后的重要任务。

在以下紧急情况下需要执行强制的故障转移：

在对 WSFC 群集执行强制仲裁（“强制仲裁” ）后，你需要强制故障转移每个可用性组（可能会丢失数据）。强制故障转移是必需的，因为 WSFC 群集值的真实状态可能已丢失。如果您能够在托管先前作为主副本的服务器实例上强制故障转移，或者将故障转移到在强制仲裁之前已同步的次要副本，则可以避免数据丢失。有关详细信息，请参阅本文后面的 “强制仲裁后避免数据丢失的潜在方法”。

重要

如果仲裁数量通过自然方式重新获得，而不是强制恢复，则可用性副本将执行恢复正常过程。如果在重新获得仲裁后主副本仍不可用，则您可以执行计划的手动故障转移到同步的辅助副本。

有关强制仲裁的详细信息，请参阅通过强制仲裁进行 WSFC 灾难恢复 (SQL Server)。有关为什么需要在强制仲裁后强制执行故障转移的信息，请参阅故障转移和故障转移模式（Always On 可用性组）。
在 WSFC 群集具有正常仲裁时，如果主要副本变得不可用，您可以强制故障转移（可能丢失数据）到角色处于 SECONDARY 或 RESOLVING 状态的任何副本。如果可能，应强制故障转移到在主副本丢失时处于同步状态的同步提交辅助副本。

提示

在 WSFC 群集具有运行状况正常的仲裁时，如果对已同步的辅助副本发出强制故障转移命令，则该副本实际将执行计划的手动故障转移。

有关强制故障转移的先决条件和建议以及使用强制故障转移从灾难性故障中恢复的示例方案的详细信息，请参阅示例方案：使用强制故障转移从灾难性故障中恢复，本文后面的部分。

局限性

只有在 Windows Server 故障转移群集（WSFC）群集缺少仲裁时，才能无法执行强制故障转移。
在可用性组强制故障转移期间可能会丢失数据。此外，如果在启动强制故障转移时主副本正在运行，客户端可能仍连接到以前的主数据库。因此，我们强烈建议仅当主副本不再运行并且你愿意冒丢失数据的风险来还原对可用性组中数据库的访问权限时，才强制故障转移。
当辅助数据库处于 REVERTING 或 INITIALIZING 状态时，强制故障转移将导致数据库无法作为主数据库启动。如果数据库处于 INITIALIZING 状态，则需要从数据库备份中应用缺失的日志记录，或从头开始完全还原数据库。如果数据库处于REVERTING状态，那么您需要从备份中完全恢复数据库。
故障转移命令将在故障转移目标接受它之后立即返回。但是，在可用性组完成故障转移之后，数据库恢复操作将以异步方式执行。
故障转移时，可能不维护可用性组中数据库间的跨数据库一致性。

注意

对跨数据库和分布式事务的支持因 SQL Server 和操作系统版本而异。有关详细信息，请参阅事务 - 可用性组和数据库镜像。

先决条件

WSFC 群集具有仲裁。如果群集缺乏仲裁，请参阅通过强制仲裁进行 WSFC 灾难恢复 (SQL Server)。
必须能够连接到承载其角色处于 SECONDARY 或 RESOLVING 状态的副本的服务器实例。

建议

在主副本仍在运行时不要强制故障转移。
如果可能，请仅强制故障转移至辅助数据库处于NOT SYNCHRONIZED、SYNCHRONIZED或SYNCHRONIZING状态的故障转移目标。有关在辅助数据库处于 INITIALIZING 或 REVERTING 状态时强制故障转移影响的信息，请参阅本文前面的限制条件。
通常情况下，给定的辅助数据库的延迟（相对于主数据库）在不同的异步提交辅助副本上应该是相似的。但在强制故障转移时，数据丢失问题可能会比较突出。因此，应该考虑花些时间来确定数据库在不同辅助副本上的相对延迟。若要确定某一给定辅助数据库的哪一副本具有最少的延迟，请比较其日志末尾 LSN。更高的日志末尾 LSN 指示更少的延迟。

提示

若要比较日志序列号（LSN），请分别连接到每个在线次要副本，并查询每个本地辅助数据库在sys.dm_hadr_database_replica_states中的end_of_log_lsn值。然后，比较每个数据库的不同副本的日志末尾 LSN。不同的数据库在不同次要副本上可能具有最高的 LSN。在本例中，最合适的故障转移目标取决于对于不同数据库中的数据的相对重要性。也就是说，在这些数据库中，您最希望减小哪个数据库中可能的数据丢失？
如果客户端无法连接到原始主副本，则强制故障转移可能会导致某些“裂脑”风险。在强制故障转移之前，强烈建议您禁止客户端访问原始主副本。否则，在强制故障转移之后，原始主数据库和当前主数据库便会分别进行更新。

强制仲裁后避免数据丢失的潜在方法

在失去仲裁后的一些故障情况下，可以通过以下方法防止数据丢失：

如果原始主副本处于联机状态

如果仲裁丢失并且强制 WSFC 仲裁还原承载某一可用性组的主副本的群集节点，则对于此可用性组您可以避免数据丢失。连接到主副本并且执行强制故障转移 (FAILOVER_ALLOW_DATA_LOSS)。此操作将使主副本恢复联机状态。因为您将强制故障转移执行到原始主副本，所以没有数据丢失。
如果已同步的同步提交辅助副本处于联机状态

如果仲裁丢失并且强制 WSFC 仲裁还原承载某一可用性组的已同步辅助副本的群集节点，则对于此可用性组您应该能够避免数据丢失。如果在仲裁丢失时还原的节点已运行，您可以通过查询动态管理视图sys.dm_hadr_database_replica_cluster_states中的is_failover_ready列来确定给定数据库是否可能发生数据丢失。例如，对于名为 sql108w2k8r22的服务器实例，发出以下查询：
```
SELECT *
FROM sys.dm_hadr_database_replica_cluster_states
WHERE replica_id = (
    SELECT replica_id
    FROM sys.availability_replicas
    WHERE replica_server_name = 'sql108w2k8r22'
);
```
注意

如果还原的节点在仲裁丢失时未启动，则 is_failover_ready 可能无法反映群集在主副本脱机时的实际状态。因此， is_failover_ready 只有在发生故障时主机节点的值才好。有关详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）中的“为什么需要在强制仲裁后强制执行故障转移”。

如果 is_failover_ready = 1，数据库在群集中标记为已同步，并且已准备好进行故障转移。如果在给定次要副本上的每个数据库上均为is_failover_ready = 1，则可以在该次要副本上执行强制故障转移（FORCE_FAILOVER_ALLOW_DATA_LOSS），而无需担心数据丢失。该同步的辅助副本在主角色中处于联机状态，也就是说，作为新的主副本并且所有数据保持不变。

如果数据库未在群集中标记为已同步，并且尚未做好进行计划内手动故障转移的准备。如果强制故障转移到主机辅助副本，则此数据库上的数据会丢失。

注意

当您强制执行故障转移到次要副本时，数据丢失的程度取决于故障转移目标与主副本之间的延迟程度。遗憾的是，当 WSFC 集群缺少仲裁或强制仲裁时，无法评估数据潜在的丢失量。但请注意，一旦 WSFC 群集重新获得运行状况正常的仲裁后，您可以开始跟踪可能的数据丢失。有关详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）中的“跟踪可能的数据丢失”。

权限

ALTER AVAILABILITY GROUP需要对可用性组、CONTROL AVAILABILITY GROUP权限、ALTER ANY AVAILABILITY GROUP权限或CONTROL SERVER权限具有权限。

使用 SQL Server Management Studio

在对象资源管理器中，连接到托管在可用性组中，其副本角色处于 SECONDARY 或 RESOLVING 状态且需要故障转移的服务器实例，并展开服务器树。
依次展开“Always On 高可用性” 节点和“可用性组” 节点。
右键单击要进行故障转移的可用性组，然后选择“故障转移” 命令。
这将启动“故障转移可用性组向导”。有关详细信息，请参阅使用故障转移可用性组向导 (SQL Server Management Studio)。
强制可用性组进行故障转移之后，请完成必要的后续步骤。有关详细信息，请参阅本文后面的 “跟进：强制故障转移后的基本任务”。

使用 Transact-SQL

连接到托管副本的服务器实例，该副本在需要故障转移的可用性组中，其角色状态处于SECONDARY或RESOLVING。
使用 ALTER AVAILABILITY GROUP 语句，如下所示，其中 group_name 可用性组的名称：

ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS。

下面的示例强制 AccountsAG 可用性组故障转移到本地辅助副本。
```
ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
强制可用性组进行故障转移之后，请完成必要的后续步骤。有关详细信息，请参阅本文后面的强制故障转移后的基本任务。

使用 PowerShell

切换目录 (cd) 到负责托管角色于 SECONDARY 或 RESOLVING 状态的副本的服务器实例，这个副本处于需要故障转移的可用性组中。
使用Switch-SqlAvailabilityGroup cmdlet 和AllowDataLoss参数，采用以下形式之一：
- -AllowDataLoss
  
  默认情况下，-AllowDataLoss 参数会导致 Switch-SqlAvailabilityGroup 提醒你强制故障转移可能会导致未提交的事务丢失，并请求确认。若要继续，请输入 Y;若要取消作，请输入 N。
  
  下面的示例对可用性组 MyAg 执行强制故障转移（可能会造成数据丢失），以将故障转移到名为 SecondaryServer\InstanceName服务器实例上的次要副本。系统会提示你确认此项操作。
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss
```
- -AllowDataLoss-Force
  
  若要在不确认的情况下启动强制故障转移，请同时指定 -AllowDataLoss 和 -Force 参数。如果您要在脚本中包含此命令而无需用户交互来运行它，此操作很有用。但是，请谨慎使用 -Force 此选项，因为强制故障转移可能会导致参与可用性组的数据库丢失数据。
  
  下面的示例将对可用性组 MyAg 执行强制故障转移（可能造成数据丢失），以将故障转移到名为 SecondaryServer\InstanceName的服务器实例。该 -Force 选项禁止确认此操作。
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss -Force
```
注意

若要查看 cmdlet 的语法，请使用 Get-Help SQL Server PowerShell 环境中的 cmdlet。有关详细信息，请参阅 Get Help SQL Server PowerShell。
强制可用性组进行故障转移之后，请完成必要的后续步骤。有关详细信息，请参阅本文后面的 “跟进：强制故障转移后的基本任务”。

设置和使用 SQL Server PowerShell 提供程序

SQL Server PowerShell 提供程序

跟进：强制切换后的基本任务

执行强制故障转移之后，故障转移到的辅助副本将变成新的主副本。但是，要使客户端可访问可用性副本，您可能需要重新配置 WSFC 仲裁或调整可用性组的可用性模式配置，如下所示：
- 如果将故障转移到自动故障转移集之外：调整 WSFC 节点的仲裁投票，以反映新的可用性组配置。如果承载目标次要副本的 WSFC 节点没有 WSFC 仲裁投票，则可能需要强制 WSFC 仲裁。
  
  仅当两个可用性副本（包含之前的主副本）都配置为使用同步提交模式和自动故障转移时，自动故障转移集才存在。
  
  调整仲裁投票
- 如果将故障转移到同步提交故障转移集之外：我们建议你考虑调整新的主要副本上和其他次要副本上的可用性模式和故障转移模式，以反映你所需的同步提交模式和自动故障转移配置。
  
  注意
  
  只有在当前主副本配置为同步提交模式时，同步提交故障转移集才存在。
  
  更改可用性模式和故障转移模式
  - 更改 AlwaysOn 可用性组中副本的可用性模式
  - 更改 AlwaysOn 可用性组中副本的故障转移模式
强制故障转移后，所有辅助数据库都处于挂起状态。这包括以前的主数据库，当以前的主副本重新联机并发现它现在是次要副本时。您必须单独在每个辅助副本上手动恢复每个挂起的数据库。

在恢复辅助数据库时，辅助数据库启动与相应主数据库之间的初始数据同步。辅助数据库将回滚从未在新的主数据库上提交的所有日志记录。因此，如果担心故障转移后的主数据库可能会发生数据丢失，应尝试在某个同步提交的辅助数据库下的挂起数据库中创建数据库快照。

重要

在其任何辅助数据库被挂起时，事务日志截断在主数据库上被延迟。此外，只要任何本地数据库保持挂起状态，同步提交的次要副本的同步健康状态无法转换为 HEALTHY。

创建数据库快照
- 创建数据库快照（Transact-SQL）
恢复可用性数据库
- 恢复可用性数据库 (SQL Server)
注意

恢复所有从属数据库后，在尝试再次故障转移组之前，请等待下一个故障转移目标上的每一个从属数据库进入 SYNCHRONIZING 状态。如果任何数据库尚未 SYNCHRONIZING，则该数据库无法作为主数据库联机，并且重新建立数据库的数据同步可能需要还原事务日志、还原完整数据库备份或故障转移回以前的主副本。
如果失败的可用性副本未返回到可用性组，或者返回时间太晚，无法在新主数据库上延迟事务日志截断，请考虑从可用性组中删除失败的副本，以避免日志文件磁盘空间不足。

删除辅助副本
- 从可用性组中删除辅助副本 (SQL Server)
如果在一个或多个附加强制故障转移后执行一个强制故障转移，请在系列中的每个附加强制故障转移后执行日志备份。有关这样做的原因的详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）中“强制手动故障转移（可能丢失数据）”部分中的“强制故障转移的风险”。

执行日志备份
- 备份事务日志

示例方案：使用强制切换从灾难性故障恢复

如果主副本失败并且没有同步的辅助副本可用，则强制可用性组进行故障转移可能是适当的反应。实施强制故障转移的适宜性取决于：（1）您是否预计主副本的脱机时间会超过您的服务级别协议（SLA）所能容忍的时长，以及（2）您是否愿意为快速恢复主数据库的可用性而冒潜在的数据丢失风险。如果您决定可用性组需要强制故障转移，则实际的强制故障转移将是多步骤过程中的一个步骤。

为了说明使用强制故障转移从灾难性故障中恢复所需的步骤，本文提供了一种可能的灾难恢复方案。此示例应用场景假定某一可用性组的原始拓扑结构由一个主数据中心和一个远程数据中心构成。主数据中心承载三个同步提交可用性副本，包括主副本；而远程数据中心承载两个异步提交辅助副本。下图说明了此示例可用性组的原始拓扑结构。该可用性组由一个多子网 WSFC 群集承载，并且在主数据中心具有三个节点（节点 01、 节点 02和 节点 03），在远程数据中心有两个节点（节点 04 和 节点 05）。

可用性组的原始拓扑示意图。

主数据中心意外关闭。其三个可用性副本进入脱机状态并且其数据库变得不可用。下图说明了此故障对可用性组拓扑的影响。

主数据中心发生故障后的拓扑图。

数据库管理员 (DBA) 确定可能的最佳响应是将可用性组强制故障转移到远程异步提交辅助副本中的一个。此示例说明在您将该可用性组强制故障转移到远程副本并且最终将该可用性组返回到其原始拓扑时涉及的典型步骤。

这里介绍的故障响应包括以下两个阶段：

响应主数据中心的灾难性故障
将可用性组返回到其原始拓扑

响应主数据中心的灾难性故障

下图说明了为响应在主数据中心发生的灾难性故障而在远程数据中心执行的一系列操作。

响应主数据中心故障的步骤示意图。

在此图中的步骤说明以下步骤：

步骤	操作	链接
`1.`	数据库管理员或网络管理员确保 WSFC 群集具有运行状况正常的仲裁。在此示例中，需要强制仲裁。	WSFC 仲裁模式和投票配置 (SQL Server) 通过强制仲裁进行 WSFC 灾难恢复 (SQL Server)
`2.`	数据库管理员连接到具有最少的延迟的服务器示例（在节点 04上）并且执行强制手动故障转移。此强制故障转移将此次要副本转换为主角色并且挂起其余次要副本上的辅助数据库（在节点 05上）。	sys.dm_hadr_database_replica_states （查询 end_of_log_lsn 列。有关详细信息，请参阅本文前面的建议。
`3.`	数据库管理员手动恢复剩余辅助副本上的每个辅助数据库。	恢复可用性数据库 (SQL Server)

将可用性组返回到其原始拓扑

下图说明了在主数据中心返回到联机状态并且 WSFC 节点重新建立与 WSFC 群集的通信后将该可用性组返回到其原始拓扑的一系列操作。

重要

如果 WSFC 群集仲裁被强制进行，当脱机节点重启时，如果以下条件同时存在，它们可能会形成新的仲裁：（a）强制仲裁集中的任意节点之间没有网络连接，（b）重启节点是群集节点的大多数。这可能会导致“裂脑”情形，即可用性组将拥有两个独立的主副本，在各数据中心各有一个。强制仲裁以创建少数仲裁集之前，请参阅通过强制仲裁进行 WSFC 灾难恢复 (SQL Server)。

将组返回到其原始拓扑的步骤图。

在此图中的步骤说明以下步骤：

步骤	操作	链接
`1.`	主数据中心中的节点返回到联机状态，并且重新建立与 WSFC 群集的通信。他们的可用性副本作为挂起数据库的辅助副本上线，DBA需要尽快手动恢复这些数据库。	恢复可用性数据库 (SQL Server) 提示：如果担心故障转移后主数据库可能出现数据丢失，则应尝试在一个同步提交辅助数据库上对挂起的数据库创建数据库快照。请记住，在其任何辅助数据库被挂起时，事务日志截断在主数据库上被延迟。此外，只要任何本地数据库处于挂起状态，同步提交的次要副本的同步运行状况状态就无法转换为 `HEALTHY`。
`2.`	在恢复数据库后，数据库管理员暂时将新的主副本更改为同步提交模式。这涉及两个步骤： 1.将一个脱机可用性副本更改为异步提交模式。 2. 将新的主副本更改为同步提交模式。注意：此步骤使恢复的同步提交辅助数据库变为 `SYNCHRONIZED`。	更改 AlwaysOn 可用性组中副本的可用性模式
`3.`	节点 03 （原始主副本）上的同步提交辅助副本进入 `HEALTHY` 同步状态后，DBA 将执行计划内手动故障转移到该副本，使其再次成为主副本。节点 04 上的副本将恢复成为辅助副本。	sys.dm_hadr_database_replica_states 使用 Always On 策略查看可用性组的运行状况 (SQL Server) 对 Always On 可用性组执行手动计划故障转移（SQL Server）
`4.`	数据库管理员将连接到新的主副本，并且： 1.将以前的主副本（在远程中心）更改回异步提交模式。 2.将主数据中心中的异步提交次要副本更改回同步提交模式。	更改 AlwaysOn 可用性组中副本的可用性模式

通过

对 Always On 高可用性组进行强制手动切换（SQL Server）

局限性

先决条件

建议

强制仲裁后避免数据丢失的潜在方法

权限

使用 SQL Server Management Studio

使用 Transact-SQL

使用 PowerShell

设置和使用 SQL Server PowerShell 提供程序

跟进：强制切换后的基本任务

示例方案：使用强制切换从灾难性故障恢复

响应主数据中心的灾难性故障

将可用性组返回到其原始拓扑

相关任务

调整法定人数投票

计划的手动故障转移

故障排除

相关内容

反馈

其他资源