目前公司有一套核心交易數據庫配置了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的方法下架舊服務器和上架新服務器。目前正在測試，等切換完后，再介紹一下切換過程。
總結：
希望對大家解決問題思路上有些啟發，天無絕人之路，只要你用心，會有收獲，有時收獲還很多！！