SQL Server 集群问题请

Question

我们有 SQL Server 2008 R2 群集主动/主动/主动（a、b、c）和三个实例在此环境中运行。

我们对其中一个实例进行了测试，并进行了故障转移测试。

1. 从节点 c 到 b 的手动故障转移。3 分钟后，应用程序无法连接到 SQL Server。
2. 回到节点 c 我们一切都好，应用程序很高兴
3. 从节点 c 到 a 的手动故障转移。3 分钟后，应用程序无法连接到 SQL Server。
4. 回到节点 c 我们一切都好，应用程序很高兴

请给我一些帮助。

Answer 1

有几件事我可以立即想到。您正在运行一个多实例故障转移集群，所以理论上我希望看​​到每个节点的大小被调整为在任何给定的时间点它都可以处理所有三个实例的负载。可能情况并非如此，但也许确实如此。理想情况下，您还有一个可以处理故障的备用节点，但这听起来不像这里的情况。

您可以检查一些配置以确保您没有设置失败，我要检查的第一个是运行

sp_configure 'max server memory (MB)'

如果您run value是，2147483647那么您已将其设置为允许 SQL Server 占用它认为需要的内存。这是按实例设置的，因此当您有多个实例试图消耗所有可用 RAM 时，您将面临内存压力。

话虽如此（阅读：实际上，从这里开始），您还没有向我们提供有关您为发现应用程序停止响应的原因所做的工作的任何其他信息。只是连接到C节点的应用程序卡住了，还是原始应用程序也不起作用？这最终可能会像应用程序连接字符串连接到C节点的 IP/DNS 名称而不是 VIP 一样简单。如果是这种情况，那么当C不再为 SQL Server 提供服务时，您将无法连接。

步骤 1：确保连接字符串实际连接到实例/VIP 名称而不是节点。

步骤 1.5：（感谢 Thomas Stringer），确保给新实例足够的时间来实际恢复数据库。通过 SSMS连接到实例并查看您的数据库是否正在恢复中。

第 2 步：如果第 1 步正确，则进入运行多个实例的节点，看看发生了什么。我建议使用 PerfMon，因为“任务管理器是一个肮脏、肮脏的骗子”，并查看从内存、网络、CPU 和磁盘 IO 开始的各种子系统的指标。假设您已连接到实例并且数据库都已完全恢复，则此答案包含检查资源压力所需的大部分内容。