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/

 

 

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