AlwaysOn所在Windows Cluster失败后,如何在残存Server节点上快速
AlwaysOn是一种集合了高可用和灾难恢复两种功能的技术,它支持一个或多个数据库整体的发生故障转移,它实现了一定程度上的负载均衡,减轻了主服务器的压力,是目前最好的一种选择。那么当极端情况发生时,集群大多数节点都挂掉了,数据库所在的主节点Server也挂掉了。即当Windows 集群 Fail 时,如何快速从尚且存活的少数节点中,挑选一个来承接数据库服务。 1:测试目的Windows Failover Cluster若因故障server节点太多,会使整个Cluster fail,此时其他残存server节点上的DB数据库都会变成Recovery Pending状态,无法使用。下面的测试就是顽强还活着的节点中,挑一个使数据库快速恢复可用状态。 2:测试环境
?登录 此时的主节点,查看如下: 各节点运行正常。 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。 ? ?? 本文版权归作者所有,未经作者同意不得转载,谢谢配合!!! (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- Microsoft Azure中的Azure Web作业和Azure Scheduler之间的
- 有没有办法在Windows下使用java.util.Preferences,而不使用
- 语言无关 – 什么是全屏模式
- windows-7 – 从Windows 7到ASA 5520的L2TP / IPSec
- Windows 8上的mklink权限
- 逆向工程安装程序
- windows – Inno Setup – 如何在安装Google Chrome时告知安
- 将uint32浮点表示转换为uint8
- 命令行 – 在Windows上使用Gnuplot控制指向ImageMagick的’
- windows – 让PHP命令行逐页显示phpinfo?