SQL Server 故障转移群集数据库访问层的最佳实践是什么？

Question

原则上，SQL Server 故障转移集群将自己呈现为应用程序可以连接的虚拟机，而忽略了 SQL Server 实际上是服务器集群这一事实，因此，原则上在数据库访问层内不需要额外的逻辑应用程序。

我的问题是上述是否属实，以及在使用故障转移集群时是否对数据库访问层的操作方式进行了最佳实践修改。例如。据推测，当发生故障转移时，可能会出现延迟，这可能会导致数据库访问层出现超时错误，我们正在考虑在该层中放置逻辑以在发生超时时重试 [一些] 数据库调用（我们已经有重试逻辑用于数据库死锁）。这为影响应用程序的错误提供了另一个级别的保护。

如果发生故障切换并导致更高的应用程序级别在服务调用上收到超时错误，则这不是无缝切换。我们是否应该简单地将超时设置为允许故障转移的持续时间？

谢谢。

Answer 1

原则上，SQL Server 故障转移群集将自身呈现为一个虚拟机， 应用程序可以连接到忽略 SQL Server 的事实 实际上是一个服务器集群

啊？真的吗？这与文档相矛盾。集群基本上只不过是一个移动的 IP 地址，在不同的服务器上安装不同，几乎不是虚拟机。

原则上，在数据库访问层中不需要额外的逻辑 应用。

是和否 - 显然，失败的节点确实会终止所有正在进行的事务和连接，因此客户端必须能够对此做出反应并重试。如果客户端因连接断开而崩溃并且未重试，则它不会帮助您在一两秒后再次访问该服务器。

我们是否应该简单地将超时设置为允许故障转移的持续时间？

不，连接因故障转移而中断，因为正在进行的事务状态丢失。您需要重新建立连接，然后重新启动事务中发出的所有 Sql 命令。

请注意，从安全角度来看，集群很糟糕，您应该使用镜像 - 您有特定的风险，即出现故障的集群节点会导致数据库文件损坏，在这种情况下，故障转移会失败。镜像更健壮。