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服務，這樣業務就又恢復成為和之前對等的使用模式。

當然整個過程中都是最簡化的步驟，在每個步驟中都需要有嚴謹的思考和驗證。