[[385624]]

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

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

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

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

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

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

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

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

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

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

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