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。

 

  

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