SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

估计是春节前最后一次写博客,也估计是本年值班最后一次踩雷,感叹下成也SQL SERVER,败也SQL SERVER。

--==============================================================

场景描述:

操作系统版本 :Windows Server 2012 数据中心版本

数据库版本 :SQL SERVER 2012 企业版,版本号:11.0.5582.0

问题描述:数据库配置Alwayson环境,同机房2节点同步自动切换+跨机房异步,实现高可用性自动故障转移,由于有四个节点,因此选择奇数即3节点的群集仲裁,但当其中一节点(仲裁节点或非仲裁节点)发生硬件故障导致重启,便可能“引发”群集之间香菇丢失通信,然后群集开始对各个群集节点"已从活动故障转移群集成员身份中删除群集节点XXX",最终群集把所有仲裁节点删掉,群集自身挂掉,群集发生故障,导致上层依赖的Alwayson无法正常提供服务,处于“正在解析”状态,直到重启的节点恢复正常==>群集正常==》Alwayson正常。

假设有ABCD四个节点,AB和CD分别在两个机房,ABC三节点配置为仲裁节点,C节点发生故障,从群集时间中发现:

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

ABC三节点先后从故障群集中被移除,然后仲裁丢失群集服务关闭。

--=====================================================================

根据MS专家给出的分析,怀疑网络问题,事件1135也明显提示由于网络问题导致,而机房也查出部分出现该类故障的服务器使用了有问题的AOC线缆。

但是,问题总是在但是之后,为什么网络中喜欢在服务器宕机的时候出来凑热闹呢?一组Windows故障转移,当不出现问题的时候,一年多没有出现网络问题,就偏偏恰好在服务器宕机的时候网络“抖动”呢?因为服务器宕机产生的兴奋还是恐惧导致抖动呢?

同机房的网络应该比较值得信赖吧,一个异地机房的服务器宕机导致同一机房的网络抖动也不太科学吧。

--=====================================================================

另外一个错误提示为:A与挂掉的C握手未在40秒内完成握手

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

难道群集节点之间这么重感情么?跟一个挂掉的节点握手都等待这么长时间?要不要等到地老天荒呢?

科普下,如果出现类似状况,如果发生宕机的服务器无法尽快重启成功,在故障转移群集无法正常启动下,可以使用 net stop clussvc来停止本地群集服务器,然后再使用net start clussvc /fq来强制将本地群集服务启动,以便尽快使Alwayson回复正常提供服务。

--====================================================================

一些不太靠谱的建议,供各位参考:

1. 对于跨机房的仲裁节点,能不用还是别用吧,实在不行在同机房弄个服务器做文件共享仲裁也行

2. 两节点的故障转移群集,一定要配置文件共享或磁盘见证

3. 群集属性中策略一栏,尽量配置下““指定时段内重新启动的最多次数”:

SQL Server--疑难杂症之坑爹的Windows故障转移群集(转)

--====================================================================

吐槽下,Alwayson号称秒级别的故障转移啊,很诱惑,的确很多时候这个让DBA很放心,收到故障短信的时候,早已自动转移并恢复提供服务,DBA可以放心地洗个澡刷个牙换身衣服再来处理故障。但是理想是美好的,现实是残酷的,AO大部分情况下还算给力,出现BUG无法正常切换的几率较低(注意是较低不是没有),但架不住坑爹的Windows故障转移群集,地基不好,楼再结实也容易塌啊!

期望SQL SERVER能再次崛起,也期望作为SQL SERVER DBA能再像以前那样骄傲地说“SQL SERVER,肯定没问题”。

上一篇:C# MVC 自学笔记—6 编辑方法和编辑视图


下一篇:iOS11新特性之LargeTitle