SQL SERVER 这个数据库估计快被人遗忘了，但实际上很多IT 力量薄弱的公司的的数据库就是 SQL SERVER，大部分人认为他简单，好上手，并且问题少,SQL SERVER 本身的高可用方式主要就是 Always-on. 一般Always-on 是三台机器。下面就针对多种情况中的DOWN机后,数据库是否可以恢复正常工作,做一些相关的检验.
在安装ALWAY-ON 注意几点
1 建议三台机器
2 建议WINDOWS 2016 + SQL SERVER 2016 为低版本，这样安装后可以不使用域验证或者 证书验证。
3 需要安装WINDOWS 故障转移功能
4 建议把防火墙关闭
并且需要安装WINDOWS的故障转移功能
安装WINDOWS的故障转移集群，需要将集群内的机器的名字改为统一的后缀。
还需要将每个机器的DNS解析配置
C:\Windows\System32\drivers\etc
打开host 文件
10.50.132.205 sqls-dr-t03.gwmfc.com
10.50.132.204 sqls-dr-t02.gwmfc.com
10.50.132.203 sqls-dr-t01.gwmfc.com
安装故障转移集群， 输入服务器名称
进行测试，因为没有使用active Directory 配置可以跳过一些警告
集群本身是需要一个VIP IP 的
这里就有三个节点
下面就需要安装SQL SERVER ALWAY ON
首先需要检查 SQL SERVER 的服务中的关于AWO 功能打开了
打开任意的一个SQL SERVER数据库并创建一个数据库
需要对要做ALWAYS的数据库进行一个全备
点击创建高可用组，---新建可用组向导
添加其他节点到AWO组中
在做SQL SERVER AWO 实际上要有两个VIP 一个是WIDNOWS 的故障转移集群的VIP 一个是SQL SERVER 本身的AWO 属于高可用组的VIP
选择自动种子设定
高可用就成功安装完毕了
test 的高可用数据库就安装完毕了
下面就开始进行相关的故障转移的测试
1 从库DOWN
2 主库DOWN
3 两个从DOWN
4 一主一个从DOWN
5 全DOWN
1 从库DOWN 不会影响业务 ，我们将10.50.132.205 直接关机，还是可以通过VIP 访问数据库
在恢复了205 后，SQL SERVER 会自动启动并接入到AWO 集群内
2 主库DOWN
这边我们关闭主库， 在关闭主库，我们的应用会受到影响，已经连接的应用都会被关闭，如果
1 可用性是异步提交的，则主库不进行切换，待主库恢复后，业务可以恢复正常
2 如果可用性都是同步提交，则会进行故障自动转移
则在关闭主库后，会通过选择机制自动选择一个从库变为主库
通过VIP 206 是可以继续访问业务，业务不会受到影响
在主库开机后，（短时间，主库自动变为从库并加入到集群中）
3 两个从库DOWN
在关闭两个从库后， 数据库库主库无法访问了。
尝试将数据库恢复到可以读取的状态
无法将数据库恢复为可读取的状态
此时机器的数据库无法进度读取，或恢复单机的情况，
具体我们做了如下的工作
1 我们尝试将WINDOWS WCFS 中的10.50.1.203 windows 集群中无法删除
2 我们将10.50.132.203 的故障转移服务删除后
3 将SQL SERVER ALWAYSON 服务从SQL SERVER 服务中取消
然后数据库仍然处于挂起并且做任何操作均显示，test数据库属于可用性组，无法进行操作。
此时我们的结论是，必须回复另外至少一台服务器的情况下，才能删除可用性组，将数据库恢复为单机模式。
下图为开启 10.50.132.204 后， 10.50.132.203 的状态
结论为只要有一台机器恢复后，则应用就可以继续使用数据库服务。
必须至少有两台服务器工作的状态下，数据库才能提供服务。
4 一主一从DOWN 机
我们将 10.50.132.205 和 10.50.132.203 关掉，状态与两台从数据库DOWN机是一致的。
我们尝试将test数据库从 高可用中移除，也是失败了。
结论：只要两个数据库服务器DOWN机的情况下，数据库则陷入无法读取的失控的状态，并很难恢复。除非两个节点开启的状态下，才可以恢复数据库，或应用服务可以访问数据库。
5 三台服务器全部挂机的状态， 并且在无次序的开机后，数据库是可以恢复的，正常访问的。
另外 两台的AWO如果两台机器均挂机后，在开启的状况一般也是能恢复的，如果出现挂起的状态可以删除可用性组的方式，将数据库恢复为单机的模式，
在通过restore database 数据库名 with recovery的方式就可以将数据库恢复为单机模式。此时还需要将AWO 上的VIP 在服务的数据库上作为子IP 进行挂载提供提供对外服务。
