资源组MSSQL恢复时仲裁老是失败，咋整才能解决这问题

这个问题确实非常棘手,根源在于Windows Server故障转移集群（WSFC）的核心机制，仲裁不是SQL Server本身的功能，而是底层集群为了确保数据一致性和防止“脑裂”而设置的一道安全锁，集群里的多个节点需要投票决定谁才是老大，当赞成票超过一半时，集群服务才能正常启动，SQL Server资源组（比如你的MSSQL）才能跟着上线，老是失败，意思就是投票老是无法过半，集群一直处于“僵死”状态。

要解决这个问题,我们不能只盯着SQL Server的报错日志，必须深入检查Windows集群的日志和配置，根据微软官方文档和一些资深工程师的实践经验，可以从以下几个最可能的方向入手排查和解决。

第一，最直接的原因：检查集群的投票配置是不是出了问题。

集群里的每个节点通常都有一票,有时候还会有一个叫“磁盘见证”或“文件共享见证”的额外票源，仲裁失败，十有八九是投票成员的数量或状态不对。

• 确认哪些节点在投票： 你需要打开“故障转移集群管理器”，找到“仲裁配置”的选项，仔细看看当前参与投票的节点列表，是不是有某个节点你已经关机或者断网了，但它依然被算作一个投票成员？你有一个两节点的集群，外加一个文件共享见证，这样总票数是3票，需要至少2票才能形成仲裁，如果其中一个节点因为网络问题离线了，而你的文件共享见证也因为防火墙或权限问题无法访问，那么剩下的那个节点就只有1票，达不到2票的多数，仲裁就会失败。
• 重新配置仲裁： 如果发现确实有离线的节点不再需要参与投票，或者见证资源（比如见证磁盘或文件共享）不可用，你可以手动重新配置仲裁，根据你当前的集群节点数量，选择最合适的仲裁模型，对于两个节点的集群，强烈建议配置一个文件共享见证，这样能避免一个节点宕机导致整个集群瘫痪，操作时务必谨慎，最好在有经验的同事指导下进行，或者参考微软官方文档的步骤。

第二，非常常见但容易被忽略的原因：网络通信不稳定或DNS解析有问题。

集群节点之间依靠心跳线来互相“打招呼”，确认对方还活着，如果网络时好时坏，或者节点之间无法通过计算机名正确解析到对方的IP地址，就会导致节点被误判为离线，从而影响投票。

• 检查网络连接和心跳线： 确保所有节点之间的网络连接是稳定且低延迟的，特别是专用的心跳网卡和网络，一定要保证其通畅，可以用持续的Ping命令测试节点之间的连通性和丢包率。
• 检查DNS记录： 这是个大坑，确保每个集群节点的计算机名在DNS服务器中都有正确的A记录，并且能够被其他节点正常解析，也要检查集群名称对象（CNO）以及SQL Server的虚拟网络名称（VNN）的DNS记录是否正确，陈旧的DNS缓存也会导致问题，可以在各个节点上尝试刷新DNS缓存（命令是ipconfig /flushdns）。
• 检查防火墙： Windows防火墙或者任何第三方防火墙软件可能会阻断集群节点之间通信所需的端口，确保135、445等集群核心端口以及SQL Server使用的端口在防火墙中是放行的，一个简单的测试方法是暂时关闭防火墙（仅用于测试），看问题是否消失，如果消失，再回来仔细配置防火墙规则。

第三，检查见证资源本身的状态。

如果你的集群配置了磁盘见证或文件共享见证,那么这个“关键一票”本身的状态至关重要。

• 磁盘见证： 检查作为见证的共享磁盘是否在线且能被所有节点正常识别和访问，磁盘是否脱机？有没有磁盘错误？
• 文件共享见证： 这是最容易出问题的地方，确保指定的文件共享路径是所有集群节点都能够读写访问的，检查共享权限和NTFS权限是否设置正确，经常遇到的情况是，负责创建文件共享见证的账户权限不足，或者后来密码更改了，导致节点无法在见证共享里写入心跳信息，你需要确认集群服务账户对那个文件共享拥有完整的读写权限。

第四，迫不得已时的强制恢复方法。

如果以上方法都尝试了,情况紧急，需要尽快恢复服务，可以考虑强制启动集群，但这是一种有风险的操作，只能在确保只有一个节点上的数据是唯一正确数据的情况下使用。警告：如果操作不当，可能导致数据丢失。

这个方法通常是在剩下的最后一个节点上,以管理员身份打开PowerShell或命令提示符，使用如下命令强制启动集群服务而不进行仲裁检查：

net start clussvc /fq

或者使用集群管理器的“强制群集启动”选项，启动后，你需要尽快将其他节点重新加入集群，或者重新配置一个健康的仲裁模式，否则集群会处于一个非常脆弱的状态。

总结一下排查步骤：

1. 先看日志： 重点查看Windows系统日志中“故障转移集群”分类下的错误和警告信息，它们通常会给出非常明确的线索，比如是哪个节点失联，还是见证资源访问失败。
2. 检查投票配置： 在集群管理器中核对仲裁配置，确保投票成员符合当前实际情况。
3. 排查网络和DNS： 测试连通性，检查DNS记录和缓存。
4. 验证见证资源： 特别是文件共享见证的权限和可访问性。
5. 作为最后手段，谨慎使用强制启动。

这个问题没有一刀切的解决方案,需要你像侦探一样，根据集群日志报错的具体内容，结合上述可能性，一步步缩小范围，最终找到并解决那个捣蛋的根因。