主体“硬停机”的故障转移场景

Question

我的公司有一对 SQL Server 2005 实例的故障转移对，它们为 UL 许可的警报/呼叫中心提供数据库可用性，其中正常运行时间和可用性对生命安全至关重要。

下面是来自其中一个关键业务应用程序的 connectionStrings 的示例行（为了我们的保护而进行了消毒）：

<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
 connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
 Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
 providerName="System.Data.SqlClient" />

大约半小时前，这是我们认为的场景：

1. DBA 在指定时间向所有用户报告 Principal-DB 服务器上的硬件维护需求，并建议他们在遇到数据库连接问题时关闭并重新启动客户端应用程序。
2. DBA 从主体数据库故障转移到镜像数据库。客户端应用程序不受影响。
3. DBA 关闭 Principal-DB 服务器。
4. 某些客户端应用程序开始在池连接上超时（正如预期的那样）。遇到这些错误的用户按照 DBA 的建议关闭并重新启动。
5. 由于无法从数据库接收响应，这些客户端应用程序现在无法完全启动。
6. 欢闹随之而来。

我们的理论是，因为主要-DB不在状态，以响应连接请求在所有的，当它通常会迅速地拒绝这样的连接，如果它是在恢复状态，客户端应用程序结束了等待整个分配连接超时（默认为 20 秒）让主服务器响应，然后返回超时错误，而无需尝试连接到列出的故障转移伙伴。

快速修复是将更新推送到包含交换数据源和故障转移伙伴实例的 App.config 的客户端应用程序，因此 Mirror-DB 现在是应用程序首先尝试连接的服务器。当我们故障恢复到 Principal-DB 时，我们将不得不使用另一个应用程序更新来撤消此更改。

我需要一个更永久的修复。这不是故障转移对的预期行为，并且不允许再次发生。必须有一种方法来配置客户端应用程序，以便它在返回错误之前在这种情况下正确尝试连接到故障转移伙伴。

Answer 1

我发现了问题。

即使主服务器关闭，SQL Native Client 和 .NET SQL Data Provider 也应该无缝连接到故障转移伙伴；但是，这两个提供程序的默认配置是同时尝试 TCP/IP 和命名管道。

这个配置很好，并且可以正常工作，当服务器仍然可用但主服务器故障转移到备份时，因为网络层连接会成功，但应用级连接会立即被拒绝导致客户端尝试镜子。但是，如果主服务器没有响应，客户端将浪费整个默认的 20 秒超时时间，只是等待主服务器响应，首先通过 TCP/IP，然后通过命名管道（它本身具有默认的 20 到 30 -第二个网络级别的超时时间），因此在这种情况下，它会返回一个错误，而无需尝试备份镜像。

根据这篇 TechNet 文章，解决方案是强制客户端以一种或另一种方式仅使用 TCP/IP 进行连接，这将失败得足够快，客户端有足够的时间尝试两个合作伙伴。您可以手动配置数据提供程序来执行此操作，也可以通过指定要在连接字符串中使用的正确协议来逐个覆盖它们的默认设置。要包含的强制 TCP/IP 的参数是Network=dbmssocn;. 最重要的是，SQL 客户端在放弃并尝试故障转移镜像之前有一个“三击”方法，因此连接超时应设置得足够长，以便它能够通过此过程并至少尝试故障转移伙伴一次。30 秒的超时应该足够了。

当我们的主数据库服务器再次关闭时，我们尝试了这个修复，它确实有效。现在我们正在更新所有内部应用程序的配置文件（我们至少有六个桌面应用程序和 Intranet 站点针对这个故障转移对；这是一个广受欢迎的堆栈）。