一朋友遇到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文件给微软分析让微软解决，
总觉得微软的技术太封闭，不管怎样，有临时解决方法总比没有好。
随时随地看视频
