1 背景

作為國內(nèi)領(lǐng)先的循環(huán)經(jīng)濟產(chǎn)業(yè)公司，隨著轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)的不斷發(fā)展，基礎(chǔ)服務(wù)設(shè)施已然到了“蛻殼”的階段。

目前在用的IDC資源已趨于飽和，難以滿足后續(xù)的發(fā)展需求。

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

經(jīng)過運維同學(xué)近半年時間的籌劃和建設(shè)，全新IDC和負(fù)載均衡技術(shù)（CLB）已完成升級建設(shè)并正式投產(chǎn)，MySQL、TiDB、Redis等公共基礎(chǔ)服務(wù)需要有序進行遷移切換。對于MySQL遷移工作，面臨集群數(shù)量多、操作影響大、操作要求高等一系列難題，需要充分調(diào)研現(xiàn)狀并制定合理的方案，進一步降低對業(yè)務(wù)服務(wù)的感知。

2 遷移方案選擇

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

通過備份擴容出足夠數(shù)量的從庫，再依賴MHA（Master High Availability）系統(tǒng)發(fā)起主動切換，最終下線舊節(jié)點完成集群拓?fù)渥兏?/p>

2.2 方案二：級聯(lián)切換

通過備份搭建級聯(lián)集群，完成新集群數(shù)據(jù)同步，再通過斷級聯(lián)+域名切換的方式完成集群變更。

2.3 方案對比

• 方案一：開發(fā)量小，擴容和MHA切換都比較容易實現(xiàn)。但單個集群MHA切換時間>30s，對業(yè)務(wù)的影響時間過長，且機房遷移要求具備大規(guī)模切換能力，這就對MHA系統(tǒng)要求極高，就算是大廠自行維護的高可用系統(tǒng)，恐怕也難以保證在短時間內(nèi)依靠高可用系統(tǒng)完成百余套集群的無損切換。
• 方案二：原理簡單，切換速度快，單個集群切換時間<10s，對業(yè)務(wù)影響小。但需要大量自動化開發(fā)，例如自動擴容、自動搭建級聯(lián)集群、自動前/后置檢查、自動切換讀/寫流量等，開發(fā)成本高。

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

• 級聯(lián)讀流量切換示意圖




• 級聯(lián)寫流量切換示意圖

3 如何又快又穩(wěn)完成MySQL機房遷移

MySQL集群遷移切換的風(fēng)險非常大，稍加操作不當(dāng)就可導(dǎo)致整套集群不可用，極端情況下可能直接讓線上服務(wù)停擺。轉(zhuǎn)轉(zhuǎn)線上MySQL集群數(shù)量較多，如何又快又穩(wěn)完成MySQL機房遷移工作？

3.1 提前搭建級聯(lián)

通過備份擴容新集群，并與老集群建立級聯(lián)關(guān)系，提前搭建好所有待遷移集群級聯(lián)。由于轉(zhuǎn)轉(zhuǎn)采用單機多實例部署的架構(gòu)，新建集群時得重點考慮混合部署帶來的問題，需要提前整理各集群單實例磁盤、內(nèi)存占用數(shù)據(jù)。在開發(fā)自動搭建級聯(lián)集群腳本時，需要同時兼顧機器負(fù)載均衡和資源成本。

限制邏輯：

• 單機主庫實例不超過5個
• 單機從庫實例不超過10個
• 單機總實例不超過15個
• 單機內(nèi)存、磁盤使用率不超過85%

級聯(lián)搭建過程：

3.2 停服

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

3.3 批量操作自動化，關(guān)鍵步驟解耦

整個遷移周期內(nèi)存在大量操作，需要降低人工誤操作風(fēng)險，同時對操作時間也有一定要求，因此，所有操作都需要實現(xiàn)自動化。對于關(guān)鍵步驟應(yīng)當(dāng)解耦處理，自動化模塊需要能夠獨立運行，所有模塊相互間形成閉環(huán)，當(dāng)切換存在問題時能快速定位故障發(fā)生位置，及時回滾。在閉環(huán)中實現(xiàn)：

• 搭建級聯(lián)集群自動化
• 前/后置檢查自動化
• 批量切讀
• 批量切寫
• 自動kill舊集群連接，檢測切換后新集群連接
• 批量下線舊集群

3.4 集群分級

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

• P3集群可在白天任意時間切換
• P2集群可在晚上8點-10點操作
• P1集群需要在凌晨停服期間操作

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

3.5 切換前、后置檢查

整個切換周期內(nèi)，新、老集群的前、后置檢查必不可少。切換前后配置不一致可能引發(fā)故障，尤其是一些關(guān)鍵參數(shù)配置。

前置檢查：

• 新集群vip-rshost鏈路連通性
• buffer_pool_size
• sql_mode
• 從節(jié)點個數(shù)
• 級聯(lián)延遲
• ...

后置檢查：

• 新、老主read_only狀態(tài)
• 新、老集群業(yè)務(wù)實時連接
• 域名切換后是否指向新集群
• ...

3.6 灰度切換驗證

完成各項自動化代碼開發(fā)后，先通過測試集群進行多輪批量切換驗證，隨后按照集群等級開始線上集群切換。對于P3集群，由于切換操作對業(yè)務(wù)的影響較小，但又不同于測試集群，P3切換過程中能夠反饋線上大部分集群可能遇到的問題。采用灰度切換驗證，摸著石頭過河，把意料之外的渾水都淌一遍，不斷迭代自動化腳本。

灰度切換順序：

• 單套切換
• 小批量切換（<10）
• 大批量切換（>30）

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

• 多域名問題

按標(biāo)準(zhǔn)化運維，同一集群同一角色有且僅有一個域名，但線上集群存在一套集群使用多個主庫、從庫域名的情況。在流量切換時，需要兼容處理多域名問題

• cmdb信息不準(zhǔn)確

部分老集群元數(shù)據(jù)長時間未維護，實例信息、域名指向信息可能有誤。在遷移切換前，需要花精力去校對最新數(shù)據(jù)

4 寫在最后

轉(zhuǎn)轉(zhuǎn)線上MySQL集群規(guī)模400+，需要在9月27日凌晨停服期間完成所有集群切換。P3、P2集群在停服前已完成批量切換，剩余P1核心集群累計100+，平均耗時10s/套，半小時內(nèi)結(jié)束戰(zhàn)斗。停服期間因前期已規(guī)避大部分問題，切換過程非常流暢，后續(xù)的驗證、壓測也均符合預(yù)期。

關(guān)于作者

黃建波，轉(zhuǎn)轉(zhuǎn)DBA。主要負(fù)責(zé)轉(zhuǎn)轉(zhuǎn)MySQL運維及數(shù)據(jù)庫平臺開發(fā)。