AlwaysOn 可用性组自动故障转移不起作用

Question

在玩 AG 设置时，我启动了 WSFC，并在一个名为 DevClusterOnline 的可用性组中配置了两个节点。两个节点（DEV-AWEB5 主节点，DEV-AWEB6 辅助节点）都运行 Windows Server 2008 R2。

如果我检查我的 AG 的健康状况，我会得到：

运行下面的查询将返回此结果集：

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

如果我断开 DEV-AWEB5，我无法连接到组侦听器 (DevListener)，但是我可以 ping 它并且它会响应我的 ping。副本 - DEV-AWEB6 进入 RESOLVING 状态，我的数据库无法访问。但是，我可以手动进入 Management Studio 并将故障转移设置为 DEV-AWEB6，然后我再次启动并运行，DevListener 将再次接受连接。

考虑到这些事实证实故障转移确实有效，我已经同步提交并配置了自动故障转移，我不知道如果我的设置出现故障怎么办。

当我断开 DEV-AWEB5 的连接时，我希望我的副本会保持连接，因此 DevListener 也会保持连接。我希望自动故障转移将允许我透明地连接到 AG 侦听器。从最终用户的角度来看，使用 Web 系统应该不会注意到其中一台数据库服务器出现故障。

我被困在这里，有人能告诉我我做错了什么吗？

Answer 1

如果我断开 DEV-AWEB5

如果愿意，请定义“断开连接”。我的猜测是你保持了这个盒子，但关闭了 SQL Server。

我无法连接到组侦听器 (DevListener)，但我可以 ping 它并且它会响应我的 ping

这是因为侦听器只是代表可用性组的 WSFC 群集资源组内的虚拟网络名称 (VNN)。您的 DEV_AWEB5 节点仍然拥有集群资源组，但最有可能处于故障状态的只是 AG 集群资源。VNN 必须仍然在线（预期行为）。它只是指向拥有该资源组的任何节点（在本例中为 DEV-AWEB5）。事实上，如果您启用了 PowerShell 远程处理，并且您运行了以下命令：

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

同样，如果您可以将 RDP 导入 DEV-AWEB5（前提是您具有功能和可访问性等），那么您就可以使用侦听器名称 ( mstsc /v:YourListenerName)进行 RDP 。这只是一个 VNN。

返回的将是您拥有节点的计算机名称。

根据您的所有症状，我敢打赌您已经达到了故障转移阈值。故障转移阈值确定集群将在指定时间段内尝试对您的资源组进行故障转移的次数。这些值的默认值在6 小时内最大故障转移次数为n - 1（其中n是节点数）。您可以通过以下 WSFC PowerShell 命令看到这一点：

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

这只是为您提供设置（当然，您可以选择修改）。

证明这种情况的最佳方法是，您需要生成集群日志（系统事件日志仅详细介绍“已失败”或类似内容）。

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

默认情况下，它会被放入“C:\Windows\Cluster\Reports”文件夹中，该文件名为“Cluster.log”。

如果您要打开该集群日志，您应该能够在其中找到以下字符串，准确指出发生了什么以及发生的原因：

未故障转移组[YourClusterGroupName]、failoverCount [故障转移次数]、故障转移阈值[故障转移阈值]、nodeAvailCount [节点可用计数]。

上面的消息只是 WSFC 告诉您它不会对您的组进行故障转移，因为它发生的太多了（您达到了阈值）。

为什么会发生这种情况？只是为了防止集群资源在节点之间过于频繁地来回产生乒乓效应。

虽然在故障转移测试中达到这些阈值很常见，但在生产中它通常会指向应该调查的问题。