MySQL中間件集群平滑遷移的初步方案
最近有一套MySQL集群環境的服務器即將過保，為了避免后續帶來的一些額外問題，需要提前考慮服務器的遷移計劃，但是現在的線上業務，申請維護時間是比較困難的，而且在線變更的容忍時間是很短暫的，一般在業務層也有容錯機制，比如超時時間，容錯次數等，所以希望整個方案是可控并且變更時間對于業務側是清晰的。
整個集群的遷移計劃是按照1:1的模式進行服務器對等替換，也就意味著原來有30個服務器，要對等30個服務器來進行平移，按照之前的實踐來看，整體的遷移時間基本控制字5秒以內。
集群的整體部署架構如下，連接層使用了基于Consul的負載均衡機制，數據分片節點使用了一主一從的模式。
在遷移中，因為從庫默認是不接入業務的，所以相應的從庫的替換可以平滑實現，即用新的服務器頂上去成為新的從庫，如果可以保證IP不變，整體的拓撲結構是沒有任何變化的。
接下來，考慮的是要新增一個數據從庫節點，這個節點是基于新的從庫節點進行的級聯復制，整體結構如下：
在遷移前，需要對已有的中間件進行縮容，先能夠逐步減少為1個中間件節點，這個過程可以使用備用連接池技術實現，也可以主動觸發應用重連機制實現。
在切換的過程中，可以把原本的Consul模式降級為基于IP的模式，中間件P1連接的數據分片節點會在切換中可以先映射為S1-S4,這個過程簡單理解就是重啟中間件節點P1,在重啟的過程中會逐步釋放M1-M4上面的連接，為了保證數據的一致性，需要配置M1-S1,M2-S2,M3-S3,M4-S4之間的數據雙向復制。
切換完成后就成為簡單的一主一從的拓撲結構，整體來說還是比較好理解的，這樣就整合到了新的服務器組中。
增加中間件節點，并且開啟Consul服務，這樣業務就又恢復成為和之前對等的使用模式。
當然整個過程中都是最簡化的步驟，在每個步驟中都需要有嚴謹的思考和驗證。
本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。
