核心只读数据库实例故障应急解决方案
目前公司有一套核心交易数据库配置了AlWaysON，SQL 2012版本， 1主4从， 其从库(8,14, 8.15) 这2台只读的从数据库服务器， 后台程序和wms等很多程序，都是直接配置IP连接这个2个机器，而且这2台机器已经过保，如果其中一天机器出现故障，不能使用，怎么处理？
怎么解决？
先谈谈后果：
这2台机器都有很多程序只读查询操作，一旦一台挂了，起不来（虽然概率很低）， 连故障服务器的程序，IP要改，同时程序要重启， 这些程序和服务，还很多，很容易漏。一旦出现故障，至少按小时算业务才能恢复，波及的面很广，肯定一级事故，其他最大的老板肯定会知道。
怎么处理：
自己咨询了其他同行他们的做法：
1，用域名替换IP，当IP的服务器有问题，修改DNS服务器就可以
2，使用类似的MyCAT中间件，目的读库有故障漂移到其他读库中
3，使用硬件，如携程他们的A10，可以做相关的分发
4，可以使用SQL AlwaysON的只读路由，让程序连主库，在主库做只读路由分发到读库
的确这些方法都能解决前面提到的读库故障转移：
1，用域名替换IP，同行能用，但是和他们这边的开发和运维聊了后，说这个域名替换IP的方案不可靠， 因为现在我们程序用域名，有时就出现莫名其妙的延迟问题，现在运维的技术只能哈哈，无法保证。 这个方案不行
2，使用中间件来做故障转移，和相关的框架开发，领导聊了，结论：没人没时间，不稳定，而且需要大量的测试，做不了。 这个方案不行
3，购买A10这样的硬件，贵，我们提也会被公司否。 这个方案不行
4，利用AlwaysON的只读路由, 自己也想了，现在因为主库的压力大查读库的，变成了先要到主库做一次路由分发，主库压力会更大，而且路由无法指定到那个机器，不能做流量控制。 这个方案不行
这一看市面上通用的方法一个也不适合我们，只能祈祷这2台服务器不出故障，即使出故障，也能重启后就好了。 真的只有这样的吗？ 还有其他办法解决这个难题：
这个问题一直困扰，怎么解决，没有其他办法了，看起来所有的办法都不是很好的，只能留下一个笨办法
比较好方案： 找到全部连这2台的程序配置文件和需要重启的服务，预先找到全部，一旦有故障起不来， 立即批量修改和重启。 这样就可以了
但是这个方案我一直想找开发和测试聊，看看能否做出个“故障预案“，一直没有去做。
公司一部分的数据库有MySQL，在配置keepalived，MHA，和MMM，大量的使用了虚IP，在CentOS里配置虚IP结合这些开源的组件，的确很方便，在Windows里是否也可以利用这虚IP，如果哪天8.15这个数据库服务器挂了，是否也可以虚IP
自己想了想，windows里加虚IP，就是直接加个IP就可以了。如果真的8.15挂了，我把8.15的IP加到8.14服务器，是否可行？
又出现问题：
windows的故障转移集群和AlwaysON ，连的是8.15，把IP加到8.14是对现有的集群有影响。
后来想了想：
如果真的是8.15集群出故障，启动不来，不是可以把8.15踢出故障转移集群和AlwaysON，再添加IP到8.14不就好了。 这几天测试了一下这个流程，的确是可以的。
最终的解决方案：
（8.15， 8.14） 这2台读库服务器，出现故障，无法起来时，把故障的服务器踢出故障转移集群和AlwaysON，再添加新IP到其他读服务器上，同时前提在各读库服务器加上统一的账户和密码。这样，虽然不能做到无缝切换，
但也能最大程度上减少故障时间，等后面条件成熟了，可以用其他办法。
额外收益：
目前8.15和8.14因为服务器过保，目前也准备用这个方案来做服务器替换，用这个加虚IP的方法下架旧服务器和上架新服务器，过程和方法如下：
1，切换过程详细介绍： 虚IP解决AlWaysON读库服务器过保替换
总结：
希望对大家解决问题思路上有些启发，天无绝人之路，只要你用心，会有收获，有时收获还很多！！
