我们使用 2 个 Windows Server 2019 Datacenter 节点设置了一个分布式故障转移集群,每个节点都运行 SQL Server 2019 Enterprise + SSMS18。
这两个节点位于具有两个不同 IP 子网的两个不同站点中。
每个主机都是一个 ESXI VM,只有一个 NIC(子网 A 中的主机 A,子网 B 中的主机 B)。
两个站点都通过 S2S-VPN 连接和路由之间的流量连接。
问题
我们仔细检查了每一个可能的问题,但我们无法通过 SSMS 手动故障转移具有同步数据库的可用性组
实例-> Always On 高可用性 -> 可用性组 -> -> 右键单击“故障转移”
- SQL Server 错误 41131(见附件)
故障排除
主机之间的连接已启动,“仪表板”显示两台主机正在通信、启动和同步。
Defender 防火墙规则适用于 DAG 侦听器、代理、浏览器服务。在站点 A 的 PaloAlto 防火墙上,可以检测到两个 SQL 主机之间的流量,但没有流量被拒绝。
两台主机都通过 SQL Server 代理和 SQL Server 引擎的单独服务用户运行,因此缺少
NT Authority\SYSTEM
.
AD-Clusterobject 的权限在那里,可以创建和更新任何子对象。创建后,侦听器的两个 DNS 条目和集群对象的一个 DNS 条目也在那里。
即使两台主机之间的自动播种工作正常,只有通过 SMSS18 的故障转移失败(插入的行从主机 A 复制到主机 B)。
问题
有什么想法,我们可以排除故障吗?
我附上了错误消息,但无法在线找到任何有用的信息,因为唯一连接的解决方案始终是更改 NT 帐户的权限,我们不将其用于代理或引擎。
和
错误 41131 仅在 SQL 内部的可用性组没有收到从集群端联机并达到超时(5 分钟)的良好信号时才会出现。这将是最初需要从集群日志中调查的内容。
Gaurav Rathod 在评论中已经建议了这一点:
但是,这个问题的答案,也是一个评论(如果他们已经被清理):
我可以向您保证,其中一个日志中肯定有一个条目可以提示正在发生的事情。如果在初步梳理之后,您认为没有任何帮助,那么可能是时候让其他人(顾问 :wink:、Microsoft 支持等)参与来解决这些类型的问题。
有时,如果它很容易重现,那么在重现问题之前将日志级别设置为调试集群会很有帮助 - 只是为了添加更多细节,尽管默认级别应该可以帮助您入门。
通常,在这些情况下。您首先要查找
MoveGroup
调用以查看集群在目标节点上从何处开始移动。然后,您将能够遵循集群所采用的逻辑以及在使组的资源联机时发生的任何错误。感谢你们所有人,他们花时间指出正确的方向。我能够解决这个问题:
正如@gurav 提到的,我确实不得不深入挖掘ClusterLogs。在第 X 次读取每一行之后,我能够在第二个节点的日志中找到这些行,并且只有第二个节点:
所以这个现象在这里被描述和解决。这本书的作者是我们应得的英雄。
因此,我从网站上检查了两个节点上的RegKey,并准确地找到了博文中写的内容(节点 B 上缺少密钥)。所以我导出了丢失的 RegKeys 并检查了SQL Configuration Manager,如果在那之后丢失的协议在那里 - 它们是。
在通过 SSMS 修复成功后,首先尝试对 AG 进行故障转移。难以置信的问题。
错误 41131,在线总是提到缺少 NT 权限,来自损坏的注册表,只有在全新系统上全新安装后,只有一台主机上的只有上帝知道这是从哪里来的。