最佳实践:如何检测SQL Server是否可用,如果不可用则进行故障转移

我正在寻找一种方法来检测SQL服务器是否响应失败(超时/异常等),以便如果试图访问该服务器的C 35;/.net程序要求关闭的服务器进行维护,它将跳转并自动尝试另一个服务器。

我想要一个解决方案,我们做SQL连接,然后得到超时。我们可以构建一个WCF服务并请求它,但在我看来这有点过分了。

多个服务器位置之间的同步不是这里的问题。

我们目前的开发平台是SQL2008express,因为它现在已经足够了,但是稍后我们可能会切换到真正的SQL2008服务器(或者是最新的)。

客户机将连接到“last known dynamic list”中的“first known”,请求“rootserver”或硬编码配置进行第一次查找。

当客户机失去连接时,它们将自动尝试重新连接到集群中的其他节点,并首先使用返回应答的任何内容。这些节点将通过我们在云中分发的其他服务进行个性化连接和共享数据。

我们知道镜像和集群可能通过大型许可证提供,但我们的设置需要更动态的“链接”,我们相信这种方法更适合我们的需要。

所以。。。具体来说:

我们需要检测SQL服务器何时脱机,何时不再可用。在交易过程中或我们试图联系的时候。

是执行“try-catch”异常处理的最佳方法,还是在查看广域网和使用C#/.net时有更好的技巧=

编辑

我收到了很多使用故障转移服务器的好主意,但是我希望使用更编程的方法,所以如果服务器可用,查询服务器的最佳方法是什么?

情况: 4个不同的SQL服务器运行在不同的WAN/IP上,每个服务器都会维护一个“其他服务器在哪里”的列表(对等)。它们将自动相互移动数据(很像一个RAID设置,数据分布在多个驱动器上)

客户机从入口点服务器重试列表并询问第一个可用的列表。 如果客户机要求服务器“停机维护”,或者数据已移动到其他服务器之一,则它必须自动询问列表中的下一个服务器。

我们要找的。。

是C#/.net中检测服务器当前不可用的最佳方法。

1. 我们可以有一个我们连接的服务,当我们解开这个,服务器就关闭了
2. 我们可以创建一个“dbConnectionSqlServer3.open()”并等待超时。
3. 我们可以投资“真正的集群服务器”,并支付大量费用+将我们自己绑定到1个SQL服务器类型(SQL平台可能在未来发生变化,因此这不是一个真正的选项)

或者你能想出一个4的数字来击败那些毫无创意的人吗?:o)