SQL Server AG集羣啓動不起來的臨時自救大招

背景

前晚一朋友遇到AG集羣發生來回切換不穩定的狀況，情急之下，朋友在命令行使用命令重啓WSFC集羣

結果重啓WSFC集羣以後，非但沒有好轉，致使整個AG沒法啓動，主副本和輔助副本都處於正在解析的狀態

 

因而這位朋友打電話向我求救，詢問了一下狀況和環境

環境

系統：Windows2012R2

數據庫：SQL Server2014 SP2

三臺機器，一個域控，兩個數據庫節點

 

---

過程

因而我查看了一下WSFC日誌和SQL Server日誌並無找到有用信息，眼看停機時間愈來愈長，只好先恢復業務，可是有AG處於正在解析狀態

沒法作任何操做，包括：備份數據庫，分離數據庫，刪除AG等

 

繼續詢問朋友數據庫備份的狀況，數據庫是天天一個完備，每一個小時一個日備，當時的狀況是距離最後一個日備已通過了40分鐘

若是還原數據庫來恢復業務，那麼就會形成40分鐘的數據丟失

 

當時急中生智，可能直接拷貝mdf文件和ldf文件並附加可以恢復數據庫，因而把兩個數據庫節點的SQL Server服務都停掉，而後直接把全部數據庫的mdf文件和

ldf文件拷貝出來，搬遷到另外一臺SQL Server服務器上，這個SQL Server服務器是單機數據庫，並無作任何高可用集羣

 

待全部數據庫搬遷完畢以後，逐個數據庫進行附加操做，想不到的是竟然能附加成功！

全部數據庫附加完畢後，建立登陸賬戶，修改程序鏈接，驗證鏈接，驗證數據，從新開啓業務，業務恢復，整個過程大概用了2個小時

 

---

後記

一天以後，AG集羣修復好了，怎麼從新把當前的業務庫從單機SQL Server的機器上從新加入到AG集羣呢？

通常人會用各類辦法把業務庫從單機SQL Server搬遷回去AG的節點，而後重作AG

今天走起君作了一個實驗，實驗環境跟朋友的環境如出一轍，發現，只須要把單機SQL Server上的全部業務庫進行分離，

而後將AG中的全部節點的SQL Server服務停掉，而後拷貝mdf文件和ldf文件回去全部AG節點覆蓋原來的數據庫文件（注意作好備份）

而後啓動AG中的各個節點的SQL Server服務，AG沒有報錯，一切回覆正常，固然這種方法停機時間會比通常方法長

 

注意點：

一、拷貝數據庫文件到單機SQL Server的時候，要選擇在主副本拷貝或者同步模式的輔助副本

二、從單機SQL Server拷貝數據庫文件到AG節點的時候，要拷貝到AG的全部節點

 

---

總結

SQL Server應該沒有對數據庫進行驗證，也就是說，對數據庫是否已經集羣化沒有進行驗證，因此這一作法才得以成功

 

 

從SQL Server2012開始剛推出AlwaysOn開始，AlwaysOn這個數據庫集羣技術就須要依賴操做系統的WSFC來作故障轉移，一直到SQL Server2017也是如此

對於WSFC的問題，即便是經驗豐富的SQL Server DBA也未必能搞定，由於牽涉到Windows深層次的原理，有些問題還要發dump文件給微軟分析讓微軟解決，

總以爲微軟的技術太封閉，無論怎樣，有臨時解決方法總比沒有好

 

 

若有不對的地方，歡迎你們拍磚o(∩_∩)o 

本文版權歸做者全部，未經做者贊成不得轉載。