标签: failover-cluster-instance

我遇到了与自动故障转移相关的异常行为，因此在关闭 SQL Server 服务的情况下自动故障转移不起作用。集群磁盘似乎仍然连接到故障节点，但我无法找出导致此行为的最终问题。如果您能帮助我理解这个问题，我将非常感谢您。

出于测试目的，我在域控制器上创建了 iSCSI 目标，并连接了 2 个启动器：

以下是有关我的集群的详细信息：

以下是有关我的 SQL Server 服务的详细信息：

以下是有关集群磁盘的详细信息（我只添加了其中一个磁盘的详细信息，因为两个磁盘是相同的）：

现在，当我关闭 SQL Server 服务时，不会发生服务的自动故障转移：

我测试了自动故障转移成功运行的其他场景：

1. 手动故障转移
2. 关闭活动节点
3. 在活动节点上禁用适配器
4. 在任务管理器中杀死sql server进程
5. 在任务管理器中杀死sql代理服务进程

在上述所有场景中，资源均成功故障转移到另一个节点。

您能否帮我弄清楚当我关闭活动节点上的 SQL Server 服务时自动故障转移出了什么问题？

• 我们有两个节点 Windows Server 集群，每个节点上安装了 SQL Server（2019 标准版）集群实例
• 有 500 个活动数据库
• 没有配置任何可用性组或任何其他 HA 解决方案
• 所有数据库均处于简单恢复模式
• VLF 数量和尺寸都不是很大
• 两个节点都是虚拟化的 Windows Server 2019，具有 64 GB 内存和 16 核。

修补被动节点并重新启动后，我们尝试故障转移到该节点。但令人惊讶的是，启动 SQL Server 服务大约需要 10 分钟，该服务挂起在更改挂起状态。在不打补丁的常规情况下，大约需要 10 秒。我从微软文档中得知，停机时间取决于故障转移时间和数据库升级脚本执行的总时间：

这一过程导致整个故障转移集群升级期间的停机时间仅限于一次故障转移时间和数据库升级脚本执行时间。

在我看来，这个停机时间似乎很长，只是在寻找以某种方式减少它的方法。如果您有任何建议，我将非常乐意倾听。

每隔约 8 小时，我就会在 Windows 群集事件中收到以下错误。在此期间，与 SQL Server 的连接会丢失。我正在努力寻找任何资源来帮助确定问题所在以及可能的解决方案。

我注意到的一件事是 Windows 集群名称与 AG 名称相同，我想知道是否存在冲突。

群集角色“SQLCluster”中类型为“SQL Server 可用性组”的群集资源“SQLCluster”失败。

群集服务无法使群集角色“SQLCluster”完全联机或脱机。一个或多个资源可能处于故障状态。这可能会影响群集角色的可用性。

该错误仅针对当前主节点生成。