频道栏目
首页 > 网络 > 其他 > 正文

数据库镜像故障转移失败怎么办

2017-03-17 10:06:48      个评论      
收藏   我要投稿

数据库镜像故障转移失败怎么办?

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

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

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

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

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

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

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

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

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

    上一篇:mfs1.6.x故障一例,血的经验教训
    下一篇:升级域控制器-从Windows 2012升级到2016案例之1
    相关文章
    图文推荐

    关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训

    版权所有: 红黑联盟--致力于做实用的IT技术学习网站