您现在的位置是:首页 > 文章详情

案例分享:数据库镜像故障转移失败

日期:2017-03-13点击:403

案例分享:数据库镜像故障转移失败

 

对于关键性数据库,我们配置了带有见证服务器的同步数据库镜像,来允许自动故障转移。一切运行正常,直到有一次数据中心的突然断电。数据库镜像执行了故障转移,但是运维反馈说应用程序挂起了。当我们手动切换回来,应用程序又正常工作。为什么应用程序没有也故障转移呢?

 

这是使用数据库镜像的合理的常见问题,像这样的生产应用失败,是因为在镜像部署后没有做故障转移测试。在失败的故障转移之后我们感到棘手。

 

为了避免生产应用停机,我们在测试环境复制了线上的镜像环境。在确认应用和数据库镜像正常工作后,我们将主服务器关机,应用完全挂起。

 

我们检查了,镜像服务器已经成功初始化了一个故障转移,并在线作为主服务器。我们也检查了镜像数据库为在线状态,可以被新的主服务器本地访问,并且主服务器也可以像被应用程序使用一样被远程客户端访问。

 

然后,我们来检查应用程序。和开发聊了下,他确认应用程序是使用ADO.NET来连接SQL Server,并使用显式客户端重定向,在SqlConnection的ConnectionString属性指定镜像服务器名。(顺便说一句,使用显式客户端重定向总是比隐式客户端重启定向要好,隐式依赖于客户端连接建立时自动缓存的镜像服务器名)

 

那为什么应用程序没有故障转移呢?

 

我深入探究应用程序是如何处理连接失败,发现根本没有应对存在的连接失败的代码!基本上,当应用程序初始化,应用会打开一个到SQL Server的连接,并且绝不尝试重连。

 

结果发现:尽管DBA部署了数据库镜像,没有和开发讨论过高可用性,因此应用程序代码没有改变。在开发修复后,应用程序连接层可以应对连接失败和执行重连逻辑,在数据库故障转移之后可以完美工作。

 

这个故事告诉我们,需要重新构建应对发生的连接失败和重连,来让故障转移正确工作。在这个案例中,如果我们在部署在生产环境之前,在测试环境尝试了数据库镜像故障转移,那客户端就会发现这个问题了。

 

具体原理和应用程序的代码示例,可参考以下文章:   



原文链接:https://blog.51cto.com/ultrasql/1905921
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章