当您的 Always On 群集失去仲裁时该怎么办？

Question

我正在审查我们公司的 DR 程序，当我在网上查找 Always On 群集丢失仲裁的解决方案时，进行比较。在找到关于集群与事务复制与可用性组主题的第一篇 SE 帖子之前，我在谷歌搜索结果中翻了三页，该帖子仅略微涉及丢失法定人数的主题。

虽然每个人都同意失去法定人数是糟糕的，并且有一些降低潜力的建议，但它仍然可能发生。我正在寻找一个经过同行评审的良好答案，以了解从 Always On 集群仲裁丢失中恢复的最佳途径。

Answer 1

AG 基于 Windows 群集。WSFC 法定人数损失程序适用。

• 通过强制仲裁的 WSFC 灾难恢复
• 强制 WSFC 群集在没有仲裁的情况下启动

WSFC 运行后，您可以根据需要强制执行 AG。执行可用性组的强制手动故障转移：

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

Answer 2

当您的 AlwaysOn 群集失去仲裁时该怎么办？

我一直处于这种情况，尤其是跨越不同国家（NY-LD-HK）的多子网集群。

如何避免多子网集群中的 Quorum Loss？

• 将群集默认设置更改为更宽松的监视状态，尤其是使用此修补程序的或属性的群集心跳设置。CrossSubnetDelayCrossSubnetThreshold
• AG 使用 WSFC，而 WSFC 又使用基于仲裁的方法来确定集群健康状况。确保正确选择和配置仲裁。这篇博文深入探讨了 AlwaysON 的仲裁投票配置

• 随着站点感知集群和云见证的引入，Windows Server 2016 发生了变化。

  延伸集群中的节点现在可以根据它们的物理位置（站点）进行分组。集群站点感知增强了集群生命周期中的关键操作，例如故障转移行为、放置策略、节点之间的心跳和仲裁行为。

  Cloud Witness是一种新型的故障转移群集仲裁见证，它利用 Microsoft Azure 作为仲裁点。它使用 Microsoft Azure Blob 存储读取/写入 Blob 文件，然后将其用作解决裂脑问题的仲裁点。

当 Quorum 丢失时该怎么办？

• 如果集群由于计划外中断/灾难而关闭，则需要手动干预。Windows 管理员或集群管理员必须手动强制仲裁 （链接回@Remus 的回答，因为它涵盖了这一点）并使幸存的节点联机。

与往常一样，要进行根本原因分析 (RCA)，请为 AlwaysON RCA 收集 Windows 群集日志 - 使用SQL Server 故障转移群集诊断日志。SQL Server 日志目录中的这些文件具有以下格式：<HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.