按標準化運維，同一集群同一角色有且僅有一個域名，但線上集群存在一套集群使用多個主庫、從庫域名的情況。在流量切換時，需要兼容處理多域名問題
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/套，半小時內結束戰斗。停服期間因前期已規避大部分問題，切換過程非常流暢，后續的驗證、壓測也均符合預期。
關于作者
黃建波，轉轉DBA。主要負責轉轉MySQL運維及數據庫平臺開發。
