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

使用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 Listener。从最终用户的角度来看，使用Web系统应该不会注意到其中一台数据库服务器出现故障。

我被困在这里，有人可以启发我做错什么吗？

如果我断开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，它告诉您它将不会对您的组进行故障转移，因为发生的次数太多（达到阈值）。

为什么会这样？只是为了防止群集资源在节点之间来回频繁的乒乓效应。

尽管在故障转移测试中达到这些阈值通常很常见，但在生产中通常会指出应调查的问题。

将MSSQL添加为通用服务资源不是答案。

这将使群集管理器负责SQL Server服务，好的，是的，它将自动进行故障转移，但是您会在SQL Server配置管理器中注意到您的服务现在设置为“手动”，表明群集管理器正在现在可以控制您的SQL Server服务。

您将由Cluster Manager负责NON Clustered Application。

它将以眼泪结束。

按照MS文档正确配置SQL Server可用性组的正确方法。

并且还要确保您没有超出“群集管理器”>“角色”>“故障转移”选项卡中定义的“故障转移参数”。

如果超出这些限制，群集将不会使资源故障转移，并且错误将发布到应用程序事件日志中。