目前公司有一套核心交易數據庫配置了AlWaysON,SQL 2012版本, 1主4從, 其從庫(8,14, 8.15) 這2臺只讀的從數據庫服務器, 後臺程序和wms等不少程序,都是直接配置IP鏈接這個2個機器,並且這2臺機器已通過保,若是其中一天機器出現故障,不能使用,怎麼處理?數據庫
這2臺機器都有不少程序只讀查詢操做,一旦一臺掛了,起不來(雖然機率很低), 連故障服務器的程序,IP要改,同時程序要重啓, 這些程序和服務,還不少,很容易漏。一旦出現故障,至少按小時算業務才能恢復,波及的面很廣,確定一級事故,其餘最大的老闆確定會知道。windows
本身諮詢了其餘同行他們的作法:服務器
1,用域名替換IP,當IP的服務器有問題,修改DNS服務器就能夠框架
2,使用相似的MyCAT中間件,目的讀庫有故障漂移到其餘讀庫中運維
3,使用硬件,如攜程他們的A10,能夠作相關的分發測試
4,可使用SQL AlwaysON的只讀路由,讓程序連主庫,在主庫作只讀路由分發到讀庫spa
的確這些方法都能解決前面提到的讀庫故障轉移:中間件
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的方法下架舊服務器和上架新服務器。目前正在測試,等切換完後,再介紹一下切換過程。
但願對你們解決問題思路上有些啓發,天無絕人之路,只要你用心,會有收穫,有時收穫還不少!!