SQL Server AlwaysOn集群启动不起来的临时自救大招

SQL Server AlwaysOn集群启动不起来的临时自救大招

 

背景

前晚一朋友遇到AlwaysOn集群发生来回切换不稳定的情况,情急之下,朋友在命令行使用命令重启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个小时

后记

一天之后,AlwaysOn集群修复好了,怎麽重新把当前的业务库从单机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 Server2012开始刚推出AlwaysOn高可用集群架构开始,AlwaysOn这个数据库集群技术就需要依赖操作系统的WSFC来做故障转移,一直到SQL Server2017也是如此,SQL Server2017开始可以在Linux上搭建AlwaysOn,使用pacemaker 和corosync作为故障转移集群管理器,经过无数次迭代,现在AlwaysOn高可用集群已经非常稳定了。

对于WSFC的问题,即使是经验丰富的SQL Server DBA也未必能搞定,因为牵涉到Windows深层次的原理,有些问题还要发dump文件给微软分析让微软解决,

但是从另一个角度来看,SQL Server 的AlwaysOn高可用架构也是足够灵活的,非常紧急的情况下只需要把数据文件直接拷贝出来再附加到别的SQLServer实例就可以使用,相比起其他数据库,这样灵活性确实非常强大

 

 

 

参考文章
https://www.mssqltips.com/sqlservertip/5437/adding-a-database-to-an-existing-sql-server-always-on-configuration/

https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-add-a-database?view=sql-server-ver16
https://www.sqlshack.com/add-sql-databases-in-an-existing-availability-group/

 

 

本文版权归作者所有,未经作者同意不得转载。

posted @ 2017-06-06 20:52  桦仔  阅读(6833)  评论(5编辑  收藏  举报