核心唯讀例項故障應急解決方案

目前公司有一套核心交易資料庫配置了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的方法下架舊伺服器和上架新伺服器。目前正在測試，等切換完後，再介紹一下切換過程。

希望對大家解決問題思路上有些啟發，天無絕人之路，只要你用心，會有收穫，有時收穫還很多！！