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

估计是春节前最后一次写博客，也估计是本年值班最后一次踩雷，感叹下成也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节点发生故障，从群集时间中发现：

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

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

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

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

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

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

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

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

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

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

一些不太靠谱的建议，供各位参考：

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

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

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

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

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

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

又是一年年关，看看身边小伙伴一个个归心似箭，突然害怕过年，混好的已经悄然睡去，混的差的早已失眠成习惯。

愿各位朋友春节快乐，有钱没钱，回家过年！

来年再见，来年再战！

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