SQL Server--疑難雜症之坑爹的Windows容錯移轉叢集

標籤：應該   奇數   情況   作業系統   always   關閉   之間   錯誤   共用   

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

估計是春節前最後一次寫部落格，也估計是本年值班最後一次踩雷，感歎下成也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容錯移轉叢集