轉轉MySQL機房遷移半小時結束戰鬥？

　　 1 背景

　　作為國內領先的迴圈經濟產業公司，隨著轉轉業務的不斷髮展，基礎服務設施已然到了“蛻殼”的階段。

　　目前在用的IDC資源已趨於飽和，難以滿足後續的發展需求。

　　同時，隨著騰訊雲提供的負載均衡技術迭代，需要將TGW（Tencent GateWay）替換為CLB（Cloud Load Balancer）。

　　經過運維同學近半年時間的籌劃和建設，全新IDC和負載均衡技術（CLB）已完成升級建設並正式投產，MySQL、TiDB、Redis等公共基礎服務需要有序進行遷移切換。對於MySQL遷移工作，面臨叢集數量多、操作影響大、操作要求高等一系列難題，需要充分調研現狀並制定合理的方案，進一步降低對業務服務的感知。

　　 2 遷移方案選擇

　　2.1 方案一：擴容+主從切換

　　透過備份擴容出足夠數量的從庫，再依賴MHA（Master High Availability）系統發起主動切換，最終下線舊節點完成叢集拓撲變更。　　

　　2.2 方案二：級聯切換

　　透過備份搭建級聯叢集，完成新叢集資料同步，再透過斷級聯+域名切換的方式完成叢集變更。　　

　　2.3 方案對比

　　方案一：開發量小，擴容和MHA切換都比較容易實現。但單個叢集MHA切換時間>30s，對業務的影響時間過長，且機房遷移要求具備大規模切換能力，這就對MHA系統要求極高，就算是大廠自行維護的高可用系統，恐怕也難以保證在短時間內依靠高可用系統完成百餘套叢集的無損切換。

　　方案二：原理簡單，切換速度快，單個叢集切換時間<10s，對業務影響小。但需要大量自動化開發，例如自動擴容、自動搭建級聯叢集、自動前/後置檢查、自動切換讀/寫流量等，開發成本高。

　　落地方案的選定，重點考慮對業務的影響，哪種方案又快又穩對業務感知又小就選哪種，毫無疑問，方案二勝出。級聯方案還有一個明顯優勢，新叢集搭建過程中可以平滑升級負載均衡（CLB替換TGW）　　

　　級聯讀流量切換示意圖　　

　　級聯寫流量切換示意圖

　　 3 如何又快又穩完成MySQL機房遷移

　　MySQL叢集遷移切換的風險非常大，稍加操作不當就可導致整套叢集不可用，極端情況下可能直接讓線上服務停擺。轉轉線上MySQL叢集數量較多，如何又快又穩完成MySQL機房遷移工作？

　　3.1 提前搭建級聯

　　透過備份擴容新叢集，並與老叢集建立級聯關係，提前搭建好所有待遷移叢集級聯。由於轉轉採用單機多例項部署的架構，新建叢集時得重點考慮混合部署帶來的問題，需要提前整理各叢集單例項磁碟、記憶體佔用資料。在開發自動搭建級聯叢集指令碼時，需要同時兼顧機器負載均衡和資源成本。

　　限制邏輯：

　　單機主庫例項不超過5個

　　單機從庫例項不超過10個

　　單機總例項不超過15個

　　單機記憶體、磁碟使用率不超過85%

　　級聯搭建過程：　　

　　3.2 停服

　　核心叢集間的上下游關係錯綜複雜，尤其是交易庫和商品庫。如果停寫一套叢集，其他好幾套關聯叢集也會受影響。另外，儘管當前部分業務方具備雙寫能力，能夠應對切換停寫帶來的影響，但叢集數量太多，並非所有業務都有足夠人力成本投入額外開發。綜合考慮，與其花費大量人工成本去梳理上下游關係和額外開發，不如在凌晨低峰期短暫停服，批次切換核心叢集。這項決定意味著我們需要具備過硬的批次操作和恢復能力，務必將操作時間進一步縮短，給測試、開發留足驗證時間，儘量減少停服時長。　　

　　3.3 批次操作自動化，關鍵步驟解耦

　　整個遷移週期記憶體在大量操作，需要降低人工誤操作風險，同時對操作時間也有一定要求，因此，所有操作都需要實現自動化。對於關鍵步驟應當解耦處理，自動化模組需要能夠獨立執行，所有模組相互間形成閉環，當切換存在問題時能快速定位故障發生位置，及時回滾。在閉環中實現：

　　搭建級聯叢集自動化

　　前/後置檢查自動化

　　批次切讀

　　批次切寫

　　自動kill舊叢集連線，檢測切換後新叢集連線

　　批次下線舊叢集

　　3.4 叢集分級

　　我們將線上叢集分為3個等級，由高到低依次為P1、P2、P3，各等級佔比約為1:1:1

　　P3叢集可在白天任意時間切換

　　P2叢集可在晚上8點-10點操作

　　P1叢集需要在凌晨停服期間操作

　　我們正不斷推進和完善叢集服務分級管理，對於達到一定規模符合等級要求的叢集，我們將投入更多精力、提供更多的資源去支撐高等級叢集的可靠性及效能。

　　3.5 切換前、後置檢查

　　整個切換週期內，新、老叢集的前、後置檢查必不可少。切換前後配置不一致可能引發故障，尤其是一些關鍵引數配置。

　　前置檢查：

　　新叢集vip-rshost鏈路連通性

　　buffer_pool_size

　　sql_mode

　　從節點個數

　　級聯延遲

　　...

　　後置檢查：

　　新、老主read_only狀態

　　新、老叢集業務實時連線

　　域名切換後是否指向新叢集

　　...

　　3.6 灰度切換驗證

　　完成各項自動化程式碼開發後，先透過測試叢集進行多輪批次切換驗證，隨後按照叢集等級開始線上叢集切換。對於P3叢集，由於切換操作對業務的影響較小，但又不同於測試叢集，P3切換過程中能夠反饋線上大部分叢集可能遇到的問題。採用灰度切換驗證，摸著石頭過河，把意料之外的渾水都淌一遍，不斷迭代自動化指令碼。

　　灰度切換順序：

　　單套切換

　　小批次切換（<10）

　　大批次切換（>30）

　　灰度切換驗證期間遇到的問題：

　　多域名問題

　　按標準化運維，同一叢集同一角色有且僅有一個域名，但線上叢集存在一套叢集使用多個主庫、從庫域名的情況。在流量切換時，需要相容處理多域名問題

　　cmdb資訊不準確

　　部分老叢集後設資料長時間未維護，例項資訊、域名指向資訊可能有誤。在遷移切換前，需要花精力去校對最新資料

　　 4 寫在最後

　　轉轉線上MySQL叢集規模400+，需要在9月27日凌晨停服期間完成所有叢集切換。P3、P2叢集在停服前已完成批次切換，剩餘P1核心叢集累計100+，平均耗時10s/套，半小時內結束戰鬥。停服期間因前期已規避大部分問題，切換過程非常流暢，後續的驗證、壓測也均符合預期。