通过强制仲裁进行 WSFC 灾难恢复 (SQL Server)
仲裁故障通常由涉及 WSFC 群集中的多个节点的系统性灾难、持久性通信故障或配置错误引起的。 从仲裁故障恢复需要手动干预。
通过强制仲裁过程进行 WSFC 灾难恢复 通过强制仲裁过程进行 WSFC 灾难恢复
开始之前
先决条件
强制仲裁过程假定在仲裁失败前存在运行状况正常的仲裁。
警告
用户应熟悉 Windows Server 故障转移群集、WSFC 仲裁模型、 SQL Server的概念和交互方式，以及环境特定的部署配置。
有关详细信息，请参阅：Windows Server 故障转移群集 (WSFC) 与 SQL Server和 WSFC 仲裁模式和投票配置 (SQL Server)
安全性
用户必须是一个域帐户，该帐户是每个 WSFC 群集节点上本地 Administrators 组的成员。
通过强制仲裁过程进行 WSFC 灾难恢复
请记住，仲裁失败将导致 WSFC 群集中的所有群集服务、SQL Server 实例和 AlwaysOn 可用性组都处于脱机状态，因为已配置的群集无法确保节点级容错。 仲裁故障意味着 WSFC 群集中的运行状况投票节点不再满足仲裁模型要求。 一些节点可能已完全失败，而另一些节点可能只是关闭了 WSFC 服务并且除失去与仲裁通信的能力之外其他方面运行状况良好。
若要使 WSFC 群集重新联机，您必须消除现有配置下仲裁故障的根源，根据需要恢复受影响的数据库，并且您可能需要在 WSFC 群集中重新配置其余的节点以反映现存的群集拓扑。
您可以在 WSFC 群集节点上使用“强制仲裁”过程来覆盖使该群集脱机的安全控制。 这样做可有效地通知 WSFC 群集挂起仲裁投票检查，并使您能够在该群集中的任意节点上将 WSFC 群集资源和 SQL Server 重新联机。
此类型的灾难恢复过程应包含以下步骤：
从仲裁故障中恢复：
确定故障的范围。 确定哪些可用性组或 SQL Server 实例是不响应的，哪些群集节点处于联机状态且可在灾后使用，并检查 Windows 事件日志和 SQL Server 系统日志。 在可行的情况下，您应保留取证数据和系统日志以供未来分析使用。
提示
在 SQL Server 2014 的响应式实例上，可以通过查询 sys.dm_hadr_availability_group_states 动态管理视图（DMV）来获取有关本地服务器实例上具有可用性副本的可用性组运行状况的信息。
在单一节点上使用强制仲裁来启动 WSFC 群集。 确定组件故障数最少的一个节点（已关闭 WSFC 群集服务的节点除外）。 确认此节点能够与其他大多数节点进行通信。
在此节点上，使用强制仲裁过程来手动强制群集联机。 为了最大程度地减少可能丢失的数据，应选择一个最后承载可用性组主副本的节点。
有关详细信息，请参阅：在无仲裁情况下强制启动 WSFC 群集
注意
在逻辑 WSFC 群集获得大多数投票并自动转换到操作的常规仲裁模式之前，强制仲裁设置会在群集范围内阻止仲裁检查。
逐一在每个其他方面运行正常的节点上正常启动 WSFC 服务。 当您在其他节点上启动该群集服务时，您无需指定强制仲裁选项。
随着每个节点上的 WSFC 服务重新联机，该服务会与其他运行状态正常的节点进行协商以同步新的群集配置状态。 记住一次只能在一个节点上执行此操作，以避免在解析群集的上一个已知状态时出现潜在的争用情况。
警告
确保您启动的每个节点都能够与其他刚刚联机的节点通信。 应考虑在其他节点上禁用 WSFC 服务。 否则，你将会面临创建多个仲裁节点集（即“裂脑”情形）的风险。 如果您在步骤 1 中的调查结果很准确，则应该不会发生这种情况。
应用新的仲裁模式和节点投票配置。 如果强制仲裁成功地重新启动了群集中的所有节点并且仲裁故障的根源得到了消除，则更改为原始仲裁模式并且不需要节点投票配置。
否则，您应评估新恢复的群集节点和可用性副本拓扑，并相应地更改每个节点的仲裁模式和投票分配。 应将未恢复的节点设置为脱机，或将其节点投票设置为零。
提示
此时，群集中的节点和 SQL Server 实例可能看起来已恢复回正常操作。 但是，可能仍然不存在运行状况正常的仲裁。 使用故障转移群集管理器或 SQL Server Management Studio 中的 AlwaysOn 面板或适当的 DMV 来确认仲裁已恢复正常。
根据需要恢复可用性组数据库副本。 非可用性组数据库应会作为常规 SQL Server 启动过程的一部分自行恢复和联机。
通过按照以下顺序将可用性组副本重新联机可以最大程度地减少可能丢失的数据并缩短恢复时间：主副本、同步辅助副本和异步辅助副本。
修复或替换失败的组件并重新验证群集。 从最初的灾难和仲裁故障中恢复之后，您应修复或替换失败的节点并对相关的 WSFC 和 AlwaysOn 配置进行相应地调整。 这可以包括删除可用性组副本、使节点从群集中退出或者在节点上平展并重新安装软件。
您必须修复或删除所有失败的可用性副本。 SQL Server 将不会截断超过最后一个可用性副本的上一个已知点的事务日志。 如果没有在可用性组中修复或删除某个失败的副本，则事务日志将会增长，因而您将面临其他副本的事务日志空间不足的风险。
注意
如果您在某一可用性组侦听器在 WSFC 群集上存在时运行 WSFC 验证配置向导，该向导将生成以下不正确的警告消息：
“网络名称‘Name:<network_name>’的 RegisterAllProviderIP 属性设为 1。对于当前群集配置，该值应设为 0。”
请忽略此消息。
根据需要，重复步骤 4。 目标是重新建立适当级别的容错和高可用性以实现正常的操作。
进行 RPO/RTO 分析。 您应分析 SQL Server 系统日志、数据库时间戳和 Windows 事件日志，以确定故障的根源，并记录实际的恢复点和恢复时间经验。