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

我正在查看我们公司的灾难恢复程序，当我在网上寻找“始终在线群集”丢失仲裁的解决方案时，可以进行比较。在搜寻结果的第一篇SE帖子之前，我在Google搜索结果中浏览了三页，该主题仅涉及群集丢失，仲裁丢失等主题。

尽管每个人都认为失败的仲裁人数是有害的，并且有一些建议可以降低这种潜力，但仍然有可能发生。我正在寻找一个很好的同行评审答案，以解决从Always On群集丢失仲裁中恢复的最佳方法。

AG基于Windows群集。WSFC的法定仲裁程序适用。

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

WSFC运行之后，您可以根据需要强制执行A​​G。对可用性组执行强制手动故障转移：

在WSFC集群上强制仲裁（强制仲裁）之后，您需要强制对每个可用性组进行故障转移（可能会丢失数据）。由于WSFC群集值的真实状态可能已经丢失，因此需要强制故障转移。但是，如果能够在承载仲裁（在强制仲裁之前是主副本）的副本的服务器实例上强制进行故障转移，或者在强制仲裁之前已同步到辅助副本的服务器实例上进行故障转移，则可以避免数据丢失。有关更多信息，请参见强制仲裁后避免数据丢失的潜在方法。

AlwaysOn群集丢失仲裁时该怎么办？

我曾经遇到过这种情况，尤其是跨不同国家（NY-LD-HK）的多子网群集。

如何避免多子网群集中的仲裁丢失？

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

• 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。

一旦我陷入停电，我们的镜像服务器就会失去连接。担心的事情之一就是确保您的应用程序指向单个实例。在网络中断时，您可以使Always On群集的所有节点都建立起来，但无法相互通信。您可以强制将故障转移到辅助节点，然后只要发生中断，您就可以拥有两个主节点，因为原始主节点将不知道强制故障转移。

根据应用程序服务器的位置，它们的配置以及访问SQL Server的能力，理论上，您可以使两个节点认为它们是主要节点，并且可以同时更改数据。解决网络问题后，节点恢复连接，原始主节点上更改的所有数据将从强制执行故障转移的节点上覆盖。这可能会导致关键数据丢失。

我曾经在SQL 2005和镜像中看到过这种情况。我们决定不强行进行故障转移并使其无法到达。原因是在最坏的情况下，如果我们必须备份并还原以重新启动镜像，那么对于我们来说这将是一个2天的过程，存在事务日志变满且无法扩展其所在磁盘的风险。