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

案例分析:
前幾天公司一台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 Cluster 跟 AlwaysOn絶對有生死與共的關係。
  • 很多時候AlwaysOn關注點是伺服器loose coupling層面,卻忘記了networking的問題。
  • 無論如何要保住File Share witness或者Disk share witness。
其他參考資料:

Comments

Popular posts from this blog

[SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

[SQL SERVER] 找出LOCK方法懶人包

[Windows7] 跨距磁碟區, 等量磁碟區, 鏡像磁碟區之區別