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

估計是春節前最后一次寫博客，也估計是本年值班最后一次踩雷，感嘆下成也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，肯定沒問題”。

?

又是一年年關，看看身邊小伙伴一個個歸心似箭，突然害怕過年，混好的已經悄然睡去，混的差的早已失眠成習慣。

愿各位朋友春節快樂，有錢沒錢，回家過年！

來年再見，來年再戰！

?

轉載于:https://www.cnblogs.com/TeyGao/p/6318189.html

總結

以上是生活随笔為你收集整理的SQL Server--疑难杂症之坑爹的Windows故障转移群集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。