我正在考虑为我的SQL Server驱动的应用程序提供高可用性选项。
要求是：
我见过两个主要选项：SQL Server故障转移群集和SQL Server镜像。
据我所知，SQL Server故障转移群集需要购买共享磁盘arrays，并且如果共享存储发生故障（因此文档build议在两个群集之间设置镜像），则不提供任何保护。
数据库镜像似乎是更便宜的select（因为它只需要两个数据库服务器和一个简单的见证框） – 但是我听说当你有大量的数据库时，它不能正常工作。 我正在开发的应用程序涉及给每个客户端自己的数据库为他们的应用程序 – 可能有数百个数据库。 由于我们有自动化系统，设置镜像是没有问题的。
我的最后一点是关于客户端连接的故障转移如何工作–SQL Server故障转移群集使用MSCS，这意味着群集对客户端不可见 – 在故障转移过程中连接尝试可能失败，但简单的重新连接将使其再次工作。 不过，据我所知，镜像要求客户端了解镜像的伙伴：如果客户端无法连接到主服务器，则会尝试从服务器。
我想知道如何在ASP.NET应用程序中的连接池工作 – 客户端连接故障切换是否意味着当连接池在每个连接上尝试主服务器时，可能会有2秒的时间（假设2000毫秒的TCP超时策略）暂停尝试？
我在某处读到，镜像可以在MSCS之上使用，这意味着客户端不需要知道镜像（所以在连接过程中不会有任何潜在的延迟，也不需要对客户端，甚至连接string） – 但是我很难得到这种方法的文档或白皮书。 但是，如果这是真的，那么最好的方法就是使用MSCS对客户端进行镜像（对于客户端无知和连接性能）。
…但是，这如何扩展到可能包含数百个镜像数据库的服务器实例呢？
你是对的，镜像和集群可以一起使用，但我认为你是如何工作的概念是一点点。 如果您希望应用程序具有镜像感知function，则必须设置连接string，使其具有在其中指定的故障转移伙伴。 现在，如果您有群集故障转移，则会发生什么情况取决于您如何设置镜像。 如果您将其设置为自动故障转移，则镜像将会接pipe，您的应用程序将连接到镜像伙伴。 如果将其设置为手动故障转移，则主服务器集群中的其他节点之一将启动SQL服务，并且主服务器将继续提供stream量。 查看http://technet.microsoft.com/en-us/library/ms191309.aspx获取更多信息。
另外，SQL 2012引入了一种新的方式来实现这个“永远在线”。 它可以用更less的努力解决你的问题。