码迷,mamicode.com
首页 > 数据库 > 详细

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

时间:2017-03-13 22:41:22      阅读:252      评论:0      收藏:0      [点我收藏+]

标签:failover   database mirroring   reconnect   

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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



本文出自 “SQL Server Deep Dive” 博客,请务必保留此出处http://ultrasql.blog.51cto.com/9591438/1905921

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

标签:failover   database mirroring   reconnect   

原文地址:http://ultrasql.blog.51cto.com/9591438/1905921

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!