估計是春節前最後一次寫博客，也估計是本年值班最後一次踩雷，感嘆下成也SQL SERVER，敗也SQL SERVER。 場景描述： 操作系統版本 ：Windows Server 2012 數據中心版本 資料庫版本 ：SQL SERVER 2012 企業版,版本號：11.0.5582.0 問題描述：數據 ...
--==============================================================
估計是春節前最後一次寫博客，也估計是本年值班最後一次踩雷，感嘆下成也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，肯定沒問題”。
又是一年年關，看看身邊小伙伴一個個歸心似箭，突然害怕過年，混好的已經悄然睡去，混的差的早已失眠成習慣。
願各位朋友春節快樂，有錢沒錢，回家過年！
來年再見，來年再戰！
