SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

先感谢一下我的同事们最先发现此问题,鸣谢:向飞、志刚、海云

最近在生产环境发现一个诡异的问题;

环境:WINDOWS 2012+SQLSERVER 2012 SP1,双节点的故障转移群集+单节点的SQLSERVER 2012 SP1实例(镜像)

生产数据库是从SQLSERVER 2008R2迁移到2012的,迁移过程很顺利,按照一般经验,可能导致数据库所有者丢失,因此在迁移后手动修改数据库所有者为sa,与此同时还有个job在做这个库的归档(定期清理历史数据到本地的历史库中,delete、insert操作);

迁移后尝试运行job均可正常执行;第二天以镜像方式做灾备,搭建完镜像环境后,归档的job报错:无法登录到服务器“(local)”。

后测试尝试重建作业也无效,再创建一个新作业,只在这个做了镜像的库上执行“select 1”,同样报错(按理说select 1是不会记录日志的,因此也就不会影响到镜像)

SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

最后通过查询代理错误日志,发现如下错误:

SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

确实,MultiSubnetFailover参数必须要开启AlwaysOn属性后才能使用。但为何在只建立镜像的环境下,SQL Agent仍会通过这个连接选项连接到镜像实例?

 

此外,我又做了两个测试:

测试A:在开启过AlwaysOn选项的单实例(非群集环境)上,先关闭AlwaysOn选项,删除并重建端点,搭建镜像环境;

测试B:在从未开启过AlwaysOn选项的单实例(非群集环境)上(新装的虚机),搭建镜像环境;

上述两次测试,JOB均可顺利执行,并未出现此前在群集环境下的问题;

由此,基本可以排除此问题受AlwaysOn选项的影响的可能,反而是对群集环境才有此类的现象;

 

目前的群集环境不便开启AlwaysOn选项,因此无法做进一步测试来验证上面的观点,有兴趣的童鞋可以继续测试一下;

SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

上一篇:微信开发本地调试工具(模拟微信客户端)


下一篇:Servlet + JSP 数据分页的实现