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