原则上，SQL Server 故障转移群集将自身呈现为应用程序可以连接到的虚拟机，而忽略了 SQL Server 实际上是服务器群集这一事实，因此，原则上在应用程序的数据库访问层中不需要其他逻辑。
我的问题是上述情况是否属实，以及使用故障转移群集时数据库访问层的运行方式是否有最佳实践修改。 例如，大概当发生故障转移时，会出现延迟，这可能会导致数据库访问层出现超时错误，我们正在考虑在该层中放置逻辑，以便在发生超时时重试 [一些] 数据库调用（我们已经有数据库死锁的重试逻辑）。这提供了另一层保护，防止影响应用程序的错误。
如果发生故障转移切换并导致更高的应用程序级别在服务调用上收到超时错误，则这不是无缝切换。我们是否应该简单地将超时设置为允许故障转移的持续时间？
谢谢。
原则上，SQL Server 故障转移群集将自身呈现为虚拟机，该虚拟机 应用程序可以连接到忽略 SQL Server 的事实 实际上是一个服务器集群
啊？真？这与文档相矛盾。集群基本上只不过是一个移动的IP地址，在不同的服务器上有不同的安装，几乎不是虚拟机。
原则上，在应用。
是和否 - 显然，故障节点确实会杀死所有正在进行的事务和连接，因此客户端必须能够对此做出反应并重试。如果客户端因连接断开而崩溃，并且不会重试，则在一两秒钟后再次访问服务器不会帮助您。
我们是否应该简单地将超时设置为允许故障转移的持续时间？
否，由于正在进行的事务状态丢失，连接会因故障转移而中断。您需要重新建立连接，然后重新启动事务中发出的所有 Sql 命令。
请注意，从安全角度来看，群集是不好的，您应该使用镜像 - 您有一个特定的风险，即发生故障的群集节点会使数据库文件损坏，在这种情况下故障转移失败。镜像更加可靠。