SQL Server AG叢集啟動不起來的臨時自救大招

標籤：dba   結果   程式   str   轉移   今天   開始   經驗   域控   

背景

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

結果重啟WSFC叢集之後，非但沒有好轉，導致整個AG無法啟動，主副本和輔助副本都處於正在解析的狀態

 

於是這位朋友打電話向我求救，詢問了一下情況和環境

環境

系統：Windows2012R2

資料庫：SQL Server2014 SP2

三台機器，一個域控，兩個資料庫節點

 

過程

於是我查看了一下WSFC日誌和SQL Server日誌並沒有找到有用資訊，眼看停機時間越來越長，只好先恢複業務，但是有AG處於正在解析狀態

無法做任何操作，包括：備份資料庫，分離資料庫，刪除AG等

 

繼續詢問朋友Database Backup的情況，資料庫是每天一個完備，每個小時一個日備，當時的情況是距離最後一個日備已經過了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 

本文著作權歸作者所有，未經作者同意不得轉載。

SQL Server AG叢集啟動不起來的臨時自救大招