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。
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！