故障转移和故障转移模式（AlwaysOn 可用性组）

适用于：SQL Server

本文介绍了 SQL Server Always On 可用性组的故障转移及其故障转移模式。

概述

在可用性组的上下文中，可用性副本的主角色和次角色通常可以通过一个称为故障转移的过程进行互换。 存在三种故障转移形式：自动故障转移（无数据丢失）、计划的手动故障转移（无数据丢失）和强制手动故障转移（可能丢失数据）。最后一种形式通常称为“强制故障转移”。 无论是自动故障转移还是计划的手动故障转移，都会保留您的所有数据。 可用性组在可用性副本级别进行故障转移。 也就是说，可用性组将故障转移到其其中一个次要副本（当前的故障转移目标）。

在故障转移期间，故障转移目标将接管主角色、恢复其数据库并且使它们作为新的主数据库处于联机状态。 以前的主副本一旦可用将切换为辅助角色，并且其数据库成为辅助数据库。 理论上，这些角色可以在彼此之间来回切换（或切换到不同的故障转移目标），以应对多次故障或出于管理需要。

给定可用性副本支持的故障转移形式由 故障转移模式 属性指定。 对于给定的可用性副本，可能的故障转移模式取决于副本 的可用性模式 ，如下所示：

• 同步提交副本支持两种设置：自动或手动。 “自动”设置支持自动故障转移和手动故障转移。 为了防止丢失数据，自动故障转移和计划的故障转移要求故障转移目标为同步提交的辅助副本且处于正常同步状态（这表示故障转移目标上的每个辅助数据库与相应的主数据库同步）。 每当次要副本不符合上述这两个条件时，它仅支持强制故障转移。 处于“RESOLVING”状态的副本也支持强制故障转移。

• 异步提交副本仅支持手动故障转移模式。 此外，由于这些副本从未同步过，因此它们仅支持强制故障转移。

SQL Server 2025 更新

SQL Server 2025 引入了以下更改：

针对持续性运行状况问题的快速故障转移

在 AlwaysOn 可用性组环境中，Windows 故障转移群集（WSFC）监视可用性组及其副本的 运行状况 。 当在主副本上检测到运行状况问题时，WSFC 会触发一系列纠正措施。 默认情况下，WSFC 会在当前副本上重启可用性组资源。 如果 WSFC 无法使资源恢复联机状态，则 WSFC 会将可用性组资源故障转移到另一个副本。 虽然此一系列纠正措施对暂时性故障有效，但可能会导致非暂时性故障的故障转移延迟。

WSFC 的故障转移行为由 RestartThreshold 值控制。 默认情况下，RestartThreshold 在 Always On 可用性组中被设置为 1，这意味着 WSFC 会在故障转移之前尝试在当前节点上重启资源。

从 SQL Server 2025 (17.x) 开始，您可以将 Always On 可用性组的 RestartThreshold 设置为 0，这会指示 WSFC 在检测到持久性运行状况问题时立即将可用性组资源进行故障转移。 这对于希望尽量减少停机时间的方案非常有用，并确保可用性组始终在正常运行的副本上可用。

这存在一个明显的权衡：

• 通过将可用性组设置为 RestartThreshold 1，可用性组可以更容忍暂时性故障，并更快地恢复联机。 但是，对于永久性故障，故障转移和停机时间可能更长。
• 将 RestartThreshold 设置为 0 会降低可用性组对暂时故障的容忍度，因此可能导致不必要的故障转移。 但是，对于永久性故障，故障转移和停机时间可能更短。

您可以使用故障转移群集管理器或 PowerShell 来设置 Always On 可用性组资源的 RestartThreshold。

例如，若要将命名RestartThreshold的可用性组设置为 ag1 0，请使用以下命令：

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

可以通过运行以下命令来验证当前 RestartThreshold 设置：

Get-ClusterResource -Name "ag1" | Format-List *

异步页面请求调度改进

当可用性组发生故障转移时，每个副本都必须找到一个共同的恢复点进行同步。 恢复点可确保可用性组保持稳定，从而能够继续传输更改。 撤销重做是此同步过程的一部分。 当辅助副本必须恢复事务以达到共同恢复点时，就会发生撤销重做。 在向启用了 FAILOVER_ALLOW_DATA_LOSS 的异步副本进行灾难恢复 (DR) 故障转移期间，“重做撤销”最为常见。

在某些情况下，进行 DR 故障转移时，随着次要副本过渡为主副本，新主副本与原始主副本（即新次要副本）之间会存在网络延迟，这会减慢新次要副本上的“重做撤销”速度。

为改善此场景下的“撤销重做”操作，SQL Server 2025 (17.x) 对同步机制进行了更新，使可用性组现在能够以异步方式分批执行页面请求。

请考虑以下事项：

• 默认情况下启用对同步机制的改进。 若要禁用改进并还原为默认行为，请在当前辅助副本或将来可能是辅助副本的可用性组中的所有副本上启用 跟踪标志 12348 。
• 如果可用性组的副本之间不存在网络延迟，此改进可能无法提升“撤销重做”的性能。

数据库在发生故障后切换到解决状态

在极少数情况下，当可用性组因短暂的 WSFC 仲裁丢失（例如临时网络断开或大多数集群节点重启）而短暂离线后，该可用性组中的一个或多个数据库可能会保持在未同步状态。 SQL Server 2025 (17.x) 中引入的可用性组恢复逻辑更新，增强了系统对此类集群仲裁丢失的内部容错能力，并可防止可用性组数据库在可用性组恢复联机后仍卡在未同步状态。

术语和定义

自动故障转移 (automatic failover)
在丢失主副本时自动发生的故障转移。 仅当当前主副本和一个辅助副本同时配置为使用自动故障转移模式，并且辅助副本当前已同步时，才支持自动故障转移。 如果主副本或次要副本的故障转移模式为“手动”，则无法进行自动故障转移。

计划的手动故障转移（无数据丢失）
计划内手动故障转移，或 手动故障转移，是指通常由数据库管理员出于管理目的而发起的故障转移。 仅当主副本和辅助副本同时配置为使用同步提交模式并且主副本和辅助副本当前均已同步（处于同步状态）时，才支持计划的手动故障转移。 当目标辅助副本同步后，即使主副本已崩溃，也可以进行手动故障转移（无数据丢失），因为辅助数据库已准备好进行故障转移。 数据库管理员需要手动启动手动故障转移。

强制故障转移（可能丢失数据）
当没有任何辅助副本与主副本同步，或主副本未运行且没有任何辅助副本已准备好进行故障转移时，数据库管理员可以启动故障转移。 强制故障转移可能导致数据丢失，且仅建议用于灾难恢复。 强制故障转移也称为强制手动故障转移，因为它只能手动启动。 这是异步提交可用性模式下支持的唯一故障转移形式。

自动故障转移集

在给定的可用性组中，仅当一对可用性副本（包括当前主副本）配置为使用同步提交模式以及自动故障转移（如果有）时，才发生这种故障转移。 仅当辅助副本当前已与主副本同步时，自动故障转移集才会生效。

同步提交故障转移集

在给定的可用性组中，若有的话，指一组配置为同步提交模式的两个或三个可用性副本（包括当前主副本）。 仅当辅助副本配置为使用手动故障转移模式，并且至少一个辅助副本当前已与主副本同步时，同步提交故障转移集才会生效。

整个故障转移集

在给定的可用性组内，其运行状态当前为联机的所有可用性副本的集合，而不考虑可用性模式和故障转移模式。 仅当当前没有辅助副本已与主副本同步时，整个故障转移集才会变为相关的。

故障转移的概述

下表概述了在不同的可用性和故障转移模式下支持的故障转移形式。 对于每对副本，其有效可用性模式和故障转移模式由主副本的模式与一个或多个次要副本的模式的交集决定。

¹ 如果在同步的辅助副本上发出强制故障转移命令，则辅助副本的行为与手动故障转移的行为相同。

在故障转移过程中，数据库不可用的时间取决于故障转移的类型及其原因。

故障转移集

就故障转移集而言，可理解为某一给定可用性组的可能的各种故障转移形式。 一个故障转移集由主副本和支持某一给定故障转移形式的辅助副本构成，如下所示：

• 自动故障转移集（可选）：在给定的可用性组内，一对配置为同步提交模式并启用自动故障转移（如有）的可用性副本（包括当前的主副本）。 仅当辅助副本当前已与主副本同步时，自动故障转移集才会生效。

• 同步提交故障转移集（可选）：在给定的可用性组内，配置为同步提交模式的一组两个或三个可用性副本（包括当前主副本），如有。 仅当辅助副本配置为使用手动故障转移模式，并且至少一个辅助副本当前已与主副本同步时，同步提交故障转移集才会生效。

• 完整故障转移集：在给定的可用性组中，所有当前运行状态为“联机”的可用性副本的集合，不论其可用性模式和故障转移模式为何。 仅当当前没有辅助副本已与主副本同步时，整个故障转移集才会变为相关的。

当您将可用性副本配置为同步提交以及自动故障转移时，此可用性副本将成为 自动故障转移集的一部分。 但是，该集是否生效则取决于当前主副本。 在某一给定时间实际可用的故障转移形式取决于当前有效的故障转移集。

例如，以一个包含四个可用性副本的可用性组为例，如下所示：

每个辅助副本的故障转移行为取决于哪个可用性副本当前是主副本。 基本上，对于给定的辅助副本而言，针对当前主副本的故障转移行为是最坏的情况。 下图说明了辅助副本的故障转移行为如何因当前主副本而异，以及它是否配置为异步提交模式（仅强制故障转移）或同步提交模式（无论是否具有自动故障转移）。

自动故障转移

在主副本变得不可用之后，自动故障转移将导致合格的辅助副本自动转换为主角色。 当承载主副本的 WSFC 节点对于承载辅助副本的节点而言为本地节点时，自动故障转移最适合。 这是因为数据同步在计算机之间消息延迟较低时效果最佳，而且客户端连接仍可保持在本地。

本节内容：

• 自动故障转移所需条件

• 自动故障转移的原理

• 启用自动故障转移

自动故障转移所需条件

自动故障转移仅在以下条件下发生：

• 存在自动故障转移集。 此自动故障转移集由主要副本和次要副本（自动故障转移目标）构成，主要副本和次要副本都配置为同步提交模式并且设置为自动故障转移。 如果主副本设置为“手动”故障转移，即使辅助副本设置为“自动”故障转移，也不会发生自动故障转移。

  有关详细信息，请参阅可用性模式（Always On 可用性组）。

• 自动故障转移目标具有正常运行的同步状态（这指示故障转移目标上的每个辅助数据库都与其相应的主数据库同步）。

  提示

  AlwaysOn 可用性组监视自动故障转移集中两个副本的运行状况。 如果任一副本失败，则该可用性组的运行状况状态将设置为“严重”。 如果辅助副本发生故障，由于自动故障转移目标不可用，因此无法进行自动故障转移。 如果主副本失败，则可用性组将故障转移到辅助副本。 在之前的主副本进入联机状态之前，将不存在任何自动故障转移目标。 在任一情况下，为了在连续出现失败这种近乎不可能发生的情况下确保可用性，我们建议您将其他辅助副本配置为自动故障转移目标。

  有关详细信息，请参阅使用 AlwaysOn 策略查看可用性组的运行状况 (SQL Server) 和更改可用性副本的故障转移模式 (SQL Server)。

• Windows Server 故障转移群集 (WSFC) 群集具有仲裁。 有关详细信息，请参阅 WSFC 仲裁模式和投票配置 (SQL Server)。

• 主副本已不可用，且您在灵活故障转移策略中定义的故障转移条件级别已满足。 有关故障转移条件级别的信息，请参阅针对可用性组的自动故障转移的灵活的故障转移策略 (SQL Server)。

自动故障转移的原理

自动故障转移将启动以下操作序列：

1. 如果承载当前主副本的服务器实例仍在运行，则它会将主数据库的状态更改为“已断开连接”并断开所有客户端的连接。

2. 如果目标辅助副本的恢复队列中有任何日志记录正在等待处理，则辅助副本会应用剩余的日志记录，以完成辅助数据库的前滚。

   注意

   将日志应用于给定数据库所需的时间取决于系统的速度、最近的工作负载以及恢复队列中的日志量。

3. 先前的辅助副本转换到主角色。 其数据库成为主数据库。 新的主副本将尽快回滚任何未提交的事务（恢复的撤消阶段）。 锁定会分离这些未提交的事务，允许当客户端使用数据库时在后台进行回滚。 此过程不会回滚任何已提交的事务。

   在连接给定的辅助数据库之前，它会短暂地标记为NOT_SYNCHRONIZED。 在回滚恢复开始前，辅助数据库可以连接到新的主数据库并快速转换为同步状态。 最佳事例是通常用于第三个同步提交的副本，该副本在故障转移之后仍然为辅助角色。

4. 然后，当承载先前主副本的服务器实例重新启动时，它将识别出其他可用性副本现在拥有主角色。 原主副本将切换为次要角色，其数据库也将成为次要数据库。 新的辅助副本连接到当前主副本，并尽快将其数据库更新为当前主数据库。 只要新的辅助副本重新同步了其数据库，就可以再次执行故障转移，但按反向执行。

配置自动故障转移

可用性副本可以配置为支持在任何一点进行自动故障转移。

配置自动故障转移

1. 确保将辅助副本配置为使用同步提交可用性模式。 有关详细信息，请参阅更改可用性副本的可用性模式 (SQL Server)。

2. 将故障转移模式设置为自动。 有关详细信息，请参阅 更改可用性副本的故障转移模式 (SQL Server)。

3. 更改可用性组的灵活故障转移策略，以指定可以导致自动故障转移的故障类别，此功能为可选的。 有关详细信息，请参阅配置灵活的故障转移策略以控制自动故障转移的条件（AlwaysOn 可用性组）和故障转移群集实例的故障转移策略。

计划的手动故障转移（无数据丢失）

在数据库管理员针对承载目标辅助副本的服务器实例发出手动故障转移命令后，手动故障转移将导致已同步的辅助副本转换为主角色。 为了支持手动故障转移，辅助副本和当前主副本必须同时配置为同步提交模式（如果有）。 可用性副本上的每个辅助数据库都必须加入到可用性组中，并与其对应的主数据库同步（也即，必须同步辅助副本）。 这可确保在先前的主数据库上已提交的每个事务，也都已在新的主数据库上提交。 因此，新的主数据库与旧的主数据库完全相同。

下图说明计划的故障转移的各个阶段：

1. 在故障转移之前，主副本位于 Node01的服务器实例上。

2. 数据库管理员启动计划的故障转移。 故障转移目标为位于 Node02的服务器实例上的可用性副本。

3. 故障转移目标（位于 Node02上）将成为新的主副本。 因为这是计划的故障转移，以前的主副本在故障转移期间切换为辅助角色，并且使其数据库立即联机作为辅助数据库。

本节内容：

• 手动故障转移所需条件

• 手动故障转移的工作原理

• 升级期间维护可用性

手动故障转移所需条件

要支持手动故障转移，当前主副本必须设置为同步提交模式，且次要副本必须：

• 配置为同步提交模式。

• 当前已与主副本同步。

若要手动对可用性组执行故障转移，您必须连接到将成为新的主副本的辅助副本。

计划的手动故障转移的工作方式

计划的手动故障转移（必须在目标辅助副本上启动）将启动以下操作序列：

1. 为了确保在原始主数据库上不发生任何新的用户事务，WSFC 群集向主副本发送要求脱机的请求。

2. 如果任何辅助数据库的恢复队列中有任何日志处于等待状态，则辅助副本将完成对辅助数据库进行前滚的操作。 所需时间取决于系统速度、最新工作负荷以及恢复队列中的日志量。 若要了解恢复队列的当前大小，请使用 Recovery Queue 性能计数器。 有关详细信息，请参阅 SQL Server，数据库副本。

   注意

   可通过限制恢复队列的大小调整故障转移时间。 不过，这会导致主副本的速度下降，以允许辅助副本与其同步。

3. 辅助副本成为新的主副本，先前的主副本成为新的辅助副本。

4. 新的主副本将回滚所有未提交的事务，并将数据库作为主数据库上线。 所有辅助数据库在连接并重新同步到新的主数据库之前，会短暂地标记为 NOT SYNCHRONIZED。 此过程不会回滚任何已提交的事务。

5. 当以前的主副本重新联机后，它将承担辅助角色，而以前的主数据库将成为辅助数据库。 新的辅助副本快速将新的辅助数据库与对应的主数据库重新同步。

   注意

   只要新的辅助副本重新同步了数据库，就可以再次执行故障转移，但按反向执行。

故障转移后，客户端必须重新连接到当前的主数据库。 有关详细信息，请参阅可用性组侦听程序、客户端连接和应用程序故障转移 (SQL Server)。

升级期间维护可用性

当您升级硬件或软件时，可用性组的数据库管理员可以使用手动故障转移来维护数据库可用性。 若要将可用性组用于软件升级，承载目标辅助副本的服务器实例和/或计算机节点必须已经收到升级。 有关详细信息，请参阅 升级 AlwaysOn 可用性组副本实例。

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

强制进行可用性组的故障转移（可能导致数据丢失）是一种灾难恢复方法，允许您将次要副本用作热备服务器。 由于强制故障转移存在数据丢失的风险，应谨慎且适度地使用。 建议仅当您必须立即将服务还原到可用性数据库并愿意承担数据丢失的风险时，才执行强制故障转移。 有关强制故障转移的先决条件和建议，以及使用强制故障转移从灾难性故障中恢复的示例应用场景的详细信息，请参阅执行可用性组的强制手动故障转移 (SQL Server)。

本节内容：

• 强制故障转移的原理

• 强制故障转移的风险

• 强制仲裁后需要强制故障转移的原因

• 跟踪可能的数据丢失

• 管理潜在的数据丢失

强制故障转移的原理

强制故障转移会启动一个将主角色转换为角色处于辅助或正在解析状态的目标副本的过程。 故障转移目标成为新的主副本，并立即将其数据库副本提供给客户端。 当以前的主副本可用时，它将转换为辅助角色，其数据库将成为辅助数据库。

所有辅助数据库（包括现在变得可用的以前的主数据库）将挂起。 根据挂起的辅助数据库以前的数据同步状态，它可能适合于补救该主数据库的未能提交的数据。 在配置为只读访问的辅助副本上，您可以查询辅助数据库以手动发现丢失的数据。 然后，可以对新的主数据库发出 Transact-SQL 语句来进行必要的更改。

强制故障转移的风险

必须明白，强制故障转移可能会导致数据丢失。 可能会丢失数据，因为目标副本无法与主副本通信，因此无法保证数据库已同步。 强制故障转移启动新的恢复分叉。 由于原始主数据库和辅助数据库位于不同的恢复分支上，因此每个数据库现在都包含其他数据库不包含的数据：每个原始主数据库包含尚未从其发送队列发送到以前的辅助数据库的任何更改（未发送日志）：以前的辅助数据库包含强制故障转移后发生的任何更改。

如果因主副本发生故障而强制进行故障转移，潜在的数据丢失取决于故障发生前是否已将任何事务日志发送给辅助副本。 在异步提交模式下，可能会始终存在累积的未发送日志。 在同步提交模式下，可能仅在辅助数据库同步之前会出现这种情况。

下表总结了在强制故障转移到该副本上时特定数据库丢失数据的可能性。

辅助数据库仅跟踪两个恢复分支，因此，如果您执行多次强制故障转移，则任何已开始与上一次强制故障转移进行数据同步的辅助数据库都可能无法继续恢复。 如果发生这种情况，则无法恢复的任何辅助数据库都需要从可用性组中删除，还原到正确的时间点，并重新加入可用性组。 在这种情况下，可能会出现状态为 103 的 1408 错误（错误: 1408，严重性: 16，状态: 103）。 还原不能跨多个恢复分叉执行，因此请确保在执行多个强制故障转移后执行日志备份。

强制仲裁后需要强制故障转移的原因

在 WSFC 集群上强制建立仲裁（强制仲裁）后，您需要对每个可用性组执行强制故障转移（可能会导致数据丢失）。 强制故障转移是必需的，因为 WSFC 群集的真实状态值可能已丢失。 由于在重新配置的 WSFC 集群上，未同步的次要副本可能会被误认为已同步，因此必须在强制建立仲裁后阻止正常故障转移。

例如，请考虑在三个节点上承载可用性组的一个 WSFC 群集：节点 A 承载主副本，节点 B 和节点 C 分别承载一个辅助副本。 节点 C 断开了与 WSFC 群集的连接，而此时该节点上的本地辅助副本处于同步状态。 但是节点 A 和节点 B 仍可以正常仲裁，可用性组仍处于联机状态。 在节点 A 上，主副本继续接受更新，在节点 B 上，辅助副本继续与主副本同步。 节点 C 上的辅助副本就会变得不同步，并且越来越滞后于主副本。 但是，由于节点 C 已断开连接，该副本仍错误地处于同步状态。

如果仲裁丢失，然后在节点 A 上强制执行，则 WSFC 群集上可用性组的同步状态应是正确的（节点 C 上的辅助副本显示为未同步状态）。 但是，如果在节点 C 上强制执行仲裁，则可用性组的同步状态将是不正确的。 群集上的同步状态将恢复为节点 C 断开连接时所处的状态（节点 C 上的辅助副本“错误地”显示为同步状态）。 由于计划性手动故障转移能保证数据安全，因此在强制多数决后，不允许使用此方式将可用性组恢复在线。

跟踪可能的数据丢失

WSFC 群集正常仲裁时，您可以估计数据库上当前可能的数据丢失量。 对于给定的辅助副本，当前可能的数据丢失量取决于本地辅助数据库滞后相应主数据库的程度。 因为滞后程度随时间而变化，我们建议您定期跟踪未同步的辅助数据库可能的数据丢失情况。 跟踪滞后情况涉及比较每个主数据库和辅助数据库的上次提交 LSN 和上次提交时间，如下所示：

1. 连接到主副本。

2. 查询 sys.dm_hadr_database_replica_states 动态管理视图的 last_commit_lsn （上次提交事务的 LSN）和 last_commit_time （上次提交时间）列。

3. 比较为每个主数据库和它的每个辅助数据库返回的值。 它们的上次提交 LSN 的差值指示滞后的程度。

4. 当某个或某组数据库上的滞后程度超过指定时间段的最大滞后程度时，您可以触发一个警报。 例如，可以通过每分钟在每个主数据库上执行的一个作业来运行查询。 如果自上次执行该作业以来，主数据库的 last_commit_time 和任意辅助数据库的相应值的差值超过恢复点目标 (RPO)（例如，5 分钟），该作业可能引发一个警报。

管理潜在的数据丢失

强制故障转移后，所有辅助数据库都将挂起。 这包括原主数据库 — 当原主副本恢复在线并发现自己已成为次要副本后。 你必须单独在每个次要副本上手动恢复每个暂停的数据库。

以前的主副本可用后，假设其数据库没有损坏，则可以尝试管理可能的数据丢失。 管理潜在数据丢失的可用方法取决于原始主副本是否已连接到新的主副本。 假设原始主副本可以访问新的主实例，则会自动透明地进行重新连接。

已重新连接原始主副本

通常，出现故障后，原始主副本在重新启动时便会迅速重新连接到其伙伴。 重新连接后，原始主副本将成为辅助副本。 其数据库将变为次要数据库并进入“SUSPENDED”状态。 除非您恢复这些数据库，否则新的次要数据库不会被回滚。

但是，挂起的数据库不可访问，因此，如果恢复给定数据库，则无法检查它们来评估哪些数据会丢失。 因此，决定是恢复还是删除辅助数据库取决于你是否愿意接受任何数据丢失，如下所示：

• 如果数据丢失不可接受，则应该从可用性组中删除数据库以对数据进行补救。

  数据库管理员现在可以恢复以前的主数据库，并尝试恢复可能已丢失的数据。 但是，当以前的主数据库联机时，它与当前主数据库不同，因此数据库管理员需要使已删除的数据库或当前主数据库无法访问客户端，以避免数据库进一步分歧并防止客户端故障转移问题。

• 如果数据丢失对于您的业务目标是可以接受的，您可以恢复辅助数据库。

  恢复辅助数据库会导致它如同步数据库第一步所述那样回滚。 如果发生故障时，仍有日志记录在发送队列中等待发送，则对应的事务将会丢失，即使这些事务已经提交也是如此。

原始主副本尚未重新连接

如果可以暂时阻止原始主副本通过网络重新连接到新的主副本，则可以检查原始主数据库以确定恢复它们时可能丢失的数据。

• 如果潜在数据丢失风险可接受

  允许原始主副本重新连接到新的主副本。 重新连接会导致新的辅助数据库被暂停。 要启动数据库的数据同步，只需恢复它。 新的辅助副本会删除该数据库的原始恢复分叉，从而丢失从未发送到以前的辅助副本或由其接收的所有事务。

• 如果数据丢失不可接受

  如果原始主数据库包含在恢复挂起的数据库时可能丢失的重要数据，则可以从可用性组中删除它，以保留原始主数据库中的数据。 这会导致数据库进入 RESTORING 状态。 此时，我们建议您尝试备份已删除数据库的日志尾部。 然后，通过从原始主数据库中导出要补救的数据，并将其导入当前主数据库来更新当前主数据库（以前的辅助数据库）。 建议尽快对已更新的主数据库执行完整数据库备份。

  然后，在托管新辅助副本的服务器实例上，可以删除已挂起的辅助数据库，并使用 RESTORE WITH NORECOVERY 还原此备份以及至少一个后续日志备份，以创建新的辅助数据库。 我们建议延迟当前主数据库的其他日志备份，直到恢复相应的辅助数据库。

相关内容

• AlwaysOn 可用性组概述 (SQL Server)
• 可用性模式（Always On 可用性组）
• Windows Server 故障转移群集 (WSFC) 与 SQL Server
• 适用于 Always On 可用性组和数据库镜像的跨数据库事务和分布式事务 (SQL Server)
• 故障转移群集实例的故障转移策略
• 用于可用性组自动故障转移的灵活故障转移策略 (SQL Server)

相关任务

配置故障转移行为

• 更改可用性副本的可用性模式 (SQL Server)
• 更改可用性副本的故障转移模式(SQL Server)
• 配置灵活故障转移策略以控制自动故障转移的条件（Always On 可用性组）

执行手动故障转移

• 对可用性组执行计划内手动故障转移 (SQL Server)
• 对可用性组执行强制手动故障转移 (SQL Server)
• 使用故障转移可用性组向导 (SQL Server Management Studio)
• 可用性组数据库的登录和作业管理 (SQL Server)

配置 WSFC 仲裁设置

• 配置群集仲裁 NodeWeight 设置
• 查看群集仲裁 NodeWeight 设置
• 强制 WSFC 群集在没有仲裁的情况下启动