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沒有報錯，一切回復正常，當然這種方法停機時間會比一般方法長
注意點：
1、拷貝數據庫文件到單機SQL Server的時候，要選擇在主副本拷貝或者同步模式的輔助副本
2、從單機SQL Server拷貝數據庫文件到AG節點的時候，要拷貝到AG的所有節點
總結
SQL Server應該沒有對數據庫進行驗證，也就是說，對數據庫是否已經集群化沒有進行驗證，所以這一做法才得以成功
從SQL Server2012開始剛推出AlwaysOn開始，AlwaysOn這個數據庫集群技術就需要依賴操作系統的WSFC來做故障轉移，一直到SQL Server2017也是如此
對於WSFC的問題，即使是經驗豐富的SQL Server DBA也未必能搞定，因為牽涉到Windows深層次的原理，有些問題還要發dump文件給微軟分析讓微軟解決，
總覺得微軟的技術太封閉，不管怎樣，有臨時解決方法總比沒有好
如有不對的地方，歡迎大家拍磚o(∩_∩)o
本文版權歸作者所有，未經作者同意不得轉載。