背景
前晚一朋友遇到AG集群发生来回切换不稳定的情况,情急之下,朋友在命令行使用命令重启WSFC集群
结果重启WSFC集群之后,非但没有好转,导致整个AG无法启动,主副本和辅助副本都处于正在解析的状态
于是这位朋友打电话向我求救,询问了一下情况和环境
环境
系统:Windows2012R2
数据库:SQL Server2014 SP2
三台机器,一个域控,两个数据库节点
过程
于是我查看了一下WSFC日志和SQL Server日志并没有找到有用信息,眼看停机时间越来越长,只好先恢复业务,但是有AG处于正在解析状态
无法做任何操作,包括:备份数据库,分离数据库,删除AG等
继续询问朋友数据库备份的情况,数据库是每天一个完备,每个小时一个日备,当时的情况是距离最后一个日备已经过了40分钟
如果还原数据库来恢复业务,那么就会造成40分钟的数据丢失
当时急中生智,可能直接拷贝mdf文件和ldf文件并附加能够恢复数据库,于是把两个数据库节点的SQL Server服务都停掉,然后直接把所有数据库的mdf文件和
ldf文件拷贝出来,搬迁到另一台SQL Server服务器上,这个SQL Server服务器是单机数据库,并没有做任何高可用集群
待所有数据库搬迁完毕之后,逐个数据库进行附加操作,想不到的是居然能附加成功!
所有数据库附加完毕后,创建登录帐户,修改程序连接,验证连接,验证数据,重新开启业务,业务恢复,整个过程大概用了2个小时
后记
一天之后,AG集群修复好了,怎麽重新把当前的业务库从单机SQL Server的机器上重新加入到AG集群呢?
一般人会用各种办法把业务库从单机SQL Server搬迁回去AG的节点,然后重做AG
今天走起君做了一个实验,实验环境跟朋友的环境一模一样,发现,只需要把单机SQL Server上的所有业务库进行分离,
然后将AG中的所有节点的SQL Server服务停掉,然后拷贝mdf文件和ldf文件回去所有AG节点覆盖原来的数据库文件(注意做好备份)
然后启动AG中的各个节点的SQL Server服务,AG没有报错,一切回复正常,当然这种方法停机时间会比一般方法长
注意点:
1、拷贝数据库文件到单机SQL Server的时候,要选择在主副本拷贝或者同步模式的辅助副本
2、从单机SQL Server拷贝数据库文件到AG节点的时候,要拷贝到AG的所有节点
总结
SQL Server应该没有对数据库进行验证,也就是说,对数据库是否已经集群化没有进行验证,所以这一做法才得以成功
从SQL Server2012开始刚推出AlwaysOn开始,AlwaysOn这个数据库集群技术就需要依赖操作系统的WSFC来做故障转移,一直到SQL Server2017也是如此
对于WSFC的问题,即使是经验丰富的SQL Server DBA也未必能搞定,因为牵涉到Windows深层次的原理,有些问题还要发dump文件给微软分析让微软解决,
总觉得微软的技术太封闭,不管怎样,有临时解决方法总比没有好
如有不对的地方,欢迎大家拍砖o(∩_∩)o
本文版权归作者所有,未经作者同意不得转载。