Windows Cluster失敗後,AlwaysOn在殘存Server節點上快速恢復DB的詳細步驟

AlwaysOn是一種集合了高可用和災難恢復兩種功能的技術，它支持一個或多個數據庫總體的發生故障轉移，它實現了必定程度上的負載均衡，減輕了主服務器的壓力，是目前最好的一種選擇。那麼當極端狀況發生時，集羣大多數節點都掛掉了，數據庫所在的主節點Server也掛掉了。即當Windows 集羣 Fail 時，如何快速從尚且存活的少數節點中，挑選一個來承接數據庫服務。

1:測試目的

Windows Failover Cluster若因故障server節點太多, 會使整個Cluster fail, 此時其餘殘存server節點上的DB數據庫都會變成Recovery Pending狀態, 沒法使用。下面的測試就是頑強還活着的節點中，挑一個使數據庫快速恢復可用狀態。

2:測試環境

Node1	Node1	Node1	ClusterIP	ListenerIP
172.XXX.XXX.112	172.XXX.XXX.113	172.XXX.XXX.114	172.XXX.XXX.115	172.XXX.XXX.117
ALWAYSONTEST01	ALWAYSONTEST02	ALWAYSONTEST03
Primary;Synchronous Commit	Secondary;Synchronous Commit	Secondary;Asynchronous Commit

 登陸 此時的主節點，查看以下：

各節點運行正常。

3:測試步驟

Step 1：關閉2個節點（XXX.112;XXX.113）使 Windows Cluster Fail，Ping Cluster IP 顯示超時。

         ----剩餘172.XXX.XXX.114 保留非同步的副本。

Step 2：登入惟一的存活的節點172.XXX XXX.114，SQL 顯示錯誤以下：

 

Step 3：刷新DB，查詢可用性組和DB的狀態已分別處於Resolving 和Recovery Pending，數據庫不可用。

 

此時Listener IP 也不可用

Step 4: 查看對應的Cluster 服務對應的Service Name

（Server ManageràLocal ServeràServices）

或(Server ManageràToolsàComponent ServicesàServices)

 Step5：手動中止羣集服務

---- net.exe stop Cluster_Name(實爲Service name)

成功關閉後172.XXX.XXX.115沒法Ping 通

 

 

  Step6：在單一節點上使用強制仲裁，藉以啓動WSFC羣集

---- net.exestart Cluster_Name/forcequorum

成功啓動後Cluster IP 能夠Ping 通；Listener IP 沒法Ping 通

經過FailOver Cluster Manger 查看節點和AG的狀態以下:

下圖爲各節點狀態；

下圖爲高可用性組的狀態

 

Step 7：重啓SQL Serveice 服務

----（個別狀況下：首先，Disable後restart，而後再Enable後restart）

Step 8：執行可用性羣組的強制性手動容錯轉移

  ---- ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS （其中 group_name 是可用性組的名稱）

 

Step 9：可用性組的狀態變爲Primary狀態，DB顯示同步，listener IP也爲可用

 

步驟概況總結：

Windows Failover Cluster若因故障server太多, 會使整個cluster fail, 此時在其餘殘存server的DB, 會在Recovery Pending狀態, 沒法使用, 採用如下可以使DB恢復使用.

中止羣集服務 --> 強制仲裁以啓動WSFC羣集 --> 重啓SQL Serveice服務 --> 執行可用性羣組的強制性手動容錯轉移.

4:補充說明

此時Restart測試過程當中關閉的節點（XXX.112;XXX.113），部署其上的DB顯示Not Synchronizing。

 

  

本文版權歸做者全部，未經做者贊成不得轉載,謝謝配合！！！