对于关键性数据库，我们配置了带有见证服务器的同步数据库镜像，来允许自动故障转移。一切运行正常，直到有一次数据中心的突然断电。数据库镜像执行了故障转移，但是运维反馈说应用程序挂起了。当我们手动切换回来，应用程序又正常工作。为什么应用程序没有也故障转移呢？
这是使用数据库镜像的合理的常见问题，像这样的生产应用失败，是因为在镜像部署后没有做故障转移测试。在失败的故障转移之后我们感到棘手。
为了避免生产应用停机，我们在测试环境复制了线上的镜像环境。在确认应用和数据库镜像正常工作后，我们将主服务器关机，应用完全挂起。
我们检查了，镜像服务器已经成功初始化了一个故障转移，并在线作为主服务器。我们也检查了镜像数据库为在线状态，可以被新的主服务器本地访问，并且主服务器也可以像被应用程序使用一样被远程客户端访问。
然后，我们来检查应用程序。和开发聊了下，他确认应用程序是使用ADO.NET来连接SQL Server，并使用显式客户端重定向，在SqlConnection的ConnectionString属性指定镜像服务器名。（顺便说一句，使用显式客户端重定向总是比隐式客户端重启定向要好，隐式依赖于客户端连接建立时自动缓存的镜像服务器名）
那为什么应用程序没有故障转移呢？
我深入探究应用程序是如何处理连接失败，发现根本没有应对存在的连接失败的代码！基本上，当应用程序初始化，应用会打开一个到SQL Server的连接，并且绝不尝试重连。
结果发现：尽管DBA部署了数据库镜像，没有和开发讨论过高可用性，因此应用程序代码没有改变。在开发修复后，应用程序连接层可以应对连接失败和执行重连逻辑，在数据库故障转移之后可以完美工作。
这个故事告诉我们，需要重新构建应对发生的连接失败和重连，来让故障转移正确工作。在这个案例中，如果我们在部署在生产环境之前，在测试环境尝试了数据库镜像故障转移，那客户端就会发现这个问题了。
具体原理和应用程序的代码示例，可参考以下文章：
-
将客户端连接到数据库镜像会话（https://msdn.microsoft.com/zh-cn/library/ms175484.aspx）
-
Implementing Application Failover with Database Mirroring（https://technet.microsoft.com/en-us/library/cc917713.aspx#EDAA）
-
Sample Application to test database mirroring failover（https://blogs.msdn.microsoft.com/grahamk/2009/01/16/sample-application-to-test-database-mirroring-failover/）
本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1905921 ，如需转载请自行联系原作者
