[[385624]]

最近有一套MySQL集群環(huán)境的服務(wù)器即將過保，為了避免后續(xù)帶來的一些額外問題，需要提前考慮服務(wù)器的遷移計劃，但是現(xiàn)在的線上業(yè)務(wù)，申請維護時間是比較困難的，而且在線變更的容忍時間是很短暫的，一般在業(yè)務(wù)層也有容錯機制，比如超時時間，容錯次數(shù)等，所以希望整個方案是可控并且變更時間對于業(yè)務(wù)側(cè)是清晰的。

整個集群的遷移計劃是按照1:1的模式進行服務(wù)器對等替換，也就意味著原來有30個服務(wù)器，要對等30個服務(wù)器來進行平移，按照之前的實踐來看，整體的遷移時間基本控制字5秒以內(nèi)。

集群的整體部署架構(gòu)如下，連接層使用了基于Consul的負(fù)載均衡機制，數(shù)據(jù)分片節(jié)點使用了一主一從的模式。

在遷移中，因為從庫默認(rèn)是不接入業(yè)務(wù)的，所以相應(yīng)的從庫的替換可以平滑實現(xiàn)，即用新的服務(wù)器頂上去成為新的從庫，如果可以保證IP不變，整體的拓?fù)浣Y(jié)構(gòu)是沒有任何變化的。

接下來，考慮的是要新增一個數(shù)據(jù)從庫節(jié)點，這個節(jié)點是基于新的從庫節(jié)點進行的級聯(lián)復(fù)制，整體結(jié)構(gòu)如下：

在遷移前，需要對已有的中間件進行縮容，先能夠逐步減少為1個中間件節(jié)點，這個過程可以使用備用連接池技術(shù)實現(xiàn)，也可以主動觸發(fā)應(yīng)用重連機制實現(xiàn)。

在切換的過程中，可以把原本的Consul模式降級為基于IP的模式，中間件P1連接的數(shù)據(jù)分片節(jié)點會在切換中可以先映射為S1-S4,這個過程簡單理解就是重啟中間件節(jié)點P1,在重啟的過程中會逐步釋放M1-M4上面的連接，為了保證數(shù)據(jù)的一致性，需要配置M1-S1,M2-S2,M3-S3,M4-S4之間的數(shù)據(jù)雙向復(fù)制。

切換完成后就成為簡單的一主一從的拓?fù)浣Y(jié)構(gòu)，整體來說還是比較好理解的，這樣就整合到了新的服務(wù)器組中。

增加中間件節(jié)點，并且開啟Consul服務(wù)，這樣業(yè)務(wù)就又恢復(fù)成為和之前對等的使用模式。

當(dāng)然整個過程中都是最簡化的步驟，在每個步驟中都需要有嚴(yán)謹(jǐn)?shù)乃伎己万炞C。

本文轉(zhuǎn)載自微信公眾號「楊建榮的學(xué)習(xí)筆記」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系楊建榮的學(xué)習(xí)筆記公眾號。