Posts

Showing posts from February, 2018

[SQL Server] Availability Group 無法正常運作復原筆記 (連案例測試)

Image
案例分析:
前幾天公司一台SQL Server突然掛點導致大停工,筆記一下這一次的經驗及研究。
SQL Server軟體部分由兩台Replicas及一個Share File Witness所組成,硬體部分兩組Replicas分別位於兩台完全沒有關連的伺服器上。

用Ping確認兩台伺服器生存情況,發現Secondary Replica沒有回應,到伺服器房間發現Secondary Replica硬體發生故障連呼吸燈都沒了,可是好奇Secondary Replica當掉為什麼整個服務會死,進入Primary Replica看看情況。

在Primary Replica中:
AlwaysOn Dashboard已經沒有回應,並且錯誤,如下:
在Object Explorer中,AlwaysOn的目錄發現Availiability Groups狀態為Resolving。Primary Replicas同樣顯示為Resolving,如下。


再進入Windows的FailOver Cluster manager,發現整個node的選項都不見了,只剩下Cluster Events可以讀取,打開來看,發現Cluster整個掛了背脊涼涼的,並且出現去不到File Share Witness的情況。


解決流程: 由於Cluster已經沒有功能已經有壯士斷臂的決心,以儘快救回服務為前題。在Primary的伺服器上進入Services,把Cluster Service Disable掉。然後進去Failover Cluster manager,嘗試 Force Cluster start without a Quorum,成功之後在Quorum Configuration中出現"Cluster is running in ForceQuorum state. brabrabra.." 資料庫還是不能連接。按照此篇文章的設定,手動設定node weight,全國最大的線上資料庫上線啦。重新測試AG設計: 事情發生後我在測試環境模擬了各種情況,結果如下:

總結: 這次經驗令我重新review了AG的技術,得出了以下的結論: AlwaysOn技術真的是AlwaysOn? 前題是Quorum Voting機制要設計好,這篇例子正正就是公司所發生的事。Windows Server Failover Cl…