Windows Cluster失败后,AlwaysOn在残存Server节点上快速恢复DB的详细步骤

迈不过友情╰ 2021-11-05 16:58 153阅读 0赞

AlwaysOn是一种集合了高可用和灾难恢复两种功能的技术，它支持一个或多个数据库整体的发生故障转移，它实现了一定程度上的负载均衡，减轻了主服务器的压力，是目前最好的一种选择。那么当极端情况发生时，集群大多数节点都挂掉了，数据库所在的主节点Server也挂掉了。即当Windows 集群 Fail 时，如何快速从尚且存活的少数节点中，挑选一个来承接数据库服务。

### **1:****测试目的** ###

Windows Failover Cluster若因故障server节点太多, 会使整个Cluster fail, 此时其他残存server节点上的DB数据库都会变成Recovery Pending状态, 无法使用。下面的测试就是顽强还活着的节点中，挑一个使数据库快速恢复可用状态。

### **2:****测试环境** ###

<table> 
 <tbody> 
  <tr> 
   <td>Node1</td> 
   <td>Node1</td> 
   <td>Node1</td> 
   <td>ClusterIP</td> 
   <td>ListenerIP</td> 
  </tr> 
  <tr> 
   <td>172.XXX.XXX.112</td> 
   <td>172.XXX.XXX.113</td> 
   <td>172.XXX.XXX.114</td> 
   <td>172.XXX.XXX.115</td> 
   <td>172.XXX.XXX.117</td> 
  </tr> 
  <tr> 
   <td>ALWAYSONTEST01</td> 
   <td> <p>ALWAYSONTEST02</p> </td> 
   <td>ALWAYSONTEST03</td> 
   <td>&nbsp;</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>Primary;Synchronous Commit</td> 
   <td> <p>Secondary;Synchronous Commit</p> </td> 
   <td>Secondary;Asynchronous Commit</td> 
   <td>&nbsp;</td> 
   <td>&nbsp;</td> 
  </tr> 
 </tbody> 
</table>

![780228-20190622170902862-1315618926.png][]

各节点运行正常。

![780228-20190622161821064-1897017820.png][]

### **3:****测试步骤** ###

Step 1：关闭2个节点（XXX.112;XXX.113）使 Windows Cluster Fail，Ping Cluster IP 显示超时。

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

![780228-20190622162107003-1605200672.png][]

Step 2：登入唯一的存活的节点172.XXX XXX.114，SQL 显示错误如下：

![780228-20190622164410804-358981606.png][]

Step 3：刷新DB，查询可用性组和DB的状态已分别处于Resolving 和Recovery Pending，数据库不可用。

![780228-20190622164710025-19286450.png][]

此时Listener IP 也不可用

![780228-20190622164839249-2142741474.png][]

Step 4: 查看对应的Cluster 服务对应的Service Name

（Server ManageràLocal ServeràServices）

![780228-20190622165141112-1619511424.png][]

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

![780228-20190622165220613-478256936.png][]

Step5：手动停止群集服务

\---- net.exe stop Cluster\_Name(实为Service name)

成功关闭后172.XXX.XXX.115无法Ping 通

![780228-20190622170756166-1410641925.png][]

Step6：在单一节点上使用强制仲裁，藉以启动WSFC群集

\---- net.exestart Cluster\_Name/forcequorum

成功启动后Cluster IP 可以Ping 通；Listener IP 无法Ping 通

![780228-20190622165916412-577825083.png][]

通过FailOver Cluster Manger 查看节点和AG的状态如下:

下图为各节点状态；

![780228-20190622170039334-883168736.png][]

下图为高可用性组的状态

![780228-20190622170124273-36760517.png][]

Step 7：重启SQL Serveice 服务

\----（个别情况下：首先，Disable后restart，然后再Enable后restart）

![780228-20190622170208344-1513952659.png][]

Step 8：执行可用性群组的强制性手动容错转移

\---- ALTER AVAILABILITY GROUP group\_name FORCE\_FAILOVER\_ALLOW\_DATA\_LOSS （其中 group\_name 是可用性组的名称）

![780228-20190622170242318-1283800714.png][]

Step 9：可用性组的状态变为Primary状态，DB显示同步，listener IP也为可用

![780228-20190622170441149-707188401.png][]

**步骤概况总结**：

Windows Failover Cluster若因故障server太多, 会使整个cluster fail, 此时在其他残存server的DB, 会在Recovery Pending状态, 无法使用, 采用以下可使DB恢复使用.

停止群集服务 --> 强制仲裁以启动WSFC群集 --> 重启SQL Serveice服务 --> 执行可用性群组的强制性手动容错转移.

### **4:补充说明** ###

此时Restart测试过程中关闭的节点（XXX.112;XXX.113），部署其上的DB显示Not Synchronizing。

![780228-20190622170555858-1173555128.png][]

**本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！**

转载于:https://www.cnblogs.com/xuliuzai/p/11069279.html

[780228-20190622170902862-1315618926.png]: /images/20211104/001e4260c80648bbbccd7296f8b27610.png
[780228-20190622161821064-1897017820.png]: /images/20211104/a9d4900e953a4096a77e49454038b614.png
[780228-20190622162107003-1605200672.png]: /images/20211104/636da113cc344cfdba757c1cea6b54ff.png
[780228-20190622164410804-358981606.png]: /images/20211104/8a73cdc5b4944fe088e193a85d5ac695.png
[780228-20190622164710025-19286450.png]: /images/20211104/c912ce76a13e49ba9f070f2351f986ce.png
[780228-20190622164839249-2142741474.png]: /images/20211104/804dc417cca2476b94751c0f64c728e4.png
[780228-20190622165141112-1619511424.png]: /images/20211104/9ad4ccbbcd80421e8ab2845ca39148af.png
[780228-20190622165220613-478256936.png]: /images/20211104/fb5517cec5fc45e7822e539b7361010e.png
[780228-20190622170756166-1410641925.png]: /images/20211104/628bcc0c6ec941e19f7b2594bb6bf4e6.png
[780228-20190622165916412-577825083.png]: /images/20211104/0cb775278fd3477f857af799426badf3.png
[780228-20190622170039334-883168736.png]: /images/20211104/61f6d8fd0f584d988ccaf413bf2ed592.png
[780228-20190622170124273-36760517.png]: /images/20211104/c4d65ca8586f4ac1bda235430d220221.png
[780228-20190622170208344-1513952659.png]: /images/20211104/e1375eb6a27e44c1898982581815b987.png
[780228-20190622170242318-1283800714.png]: /images/20211104/10bf6b87dda943428cdbf34d1294bfd6.png
[780228-20190622170441149-707188401.png]: /images/20211104/81424b5498de42cd91b0309ff427fe68.png
[780228-20190622170555858-1173555128.png]: /images/20211104/a4c65d6d04cc4efd83b929ef125c20dd.png