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也為可用
4:補充說明
此時Restart測試過程中關閉的節點（XXX.112;XXX.113），部署其上的DB顯示Not Synchronizing。
本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！