一朋友遇到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文件给微软分析让微软解决，

总觉得微软的技术太封闭，不管怎样，有临时解决方法总比没有好。