雷孝龍

去哪兒網DBA

2019年8月加入去哪兒網，擁有豐富的資料庫運維和最佳化經驗，現負責公司的MySQL/Redis運維工作，及自動化方案的實施和落地。

1. 概述

資料庫遷移拆分是我們日常運維工作中不可避免的一環，本文主要分析資料庫常用的遷移方案對應的使用場景以及優劣勢，同時分享了 Quanr 資料庫使用架構，以及架構演進過程中的實踐經驗。

2. 遷移方案

通常，一個數據遷移方案的設計，取決於原本的資料架構和業務場景。最終目標都是儘可能的對業務友好，停服時間越短越好，甚至是不停服，同時還需要保證資料的一致性。

2.1 方案一

常見的線上資料遷移方式都是先建立主從，同步資料；等待業務低峰期進行割接，主要過程如下：

新老叢集進行主從複製同步資料低峰期停止業務寫入，檢查主從同步資料一致性業務修改連線到新叢集，釋出程式驗證遷移結果

上述方法的優劣勢顯而易見。

**優勢：**架構簡單，對DBA來說很友好，只需要新建一套叢集，確保主從同步和資料一致即可。

**劣勢：**對業務來說比較不友好，需要在低峰期停止寫入；如果叢集涉及的業務多的話，必須在同一時間點停服，進行連線方式的變更釋出；可能還會面臨流量切換不完全，導致雙寫的情況。

2.2 方案二

藉助 proxy 代理進行資料遷移，具體流程如下：

分為三個階段：

建立主從複製，將原叢集的資料複製到新叢集。在原叢集上加一層 proxy，用於流量轉發，透過 proxy 來控制流量分發到哪個叢集；此時，通知業務開發，修改連線到 proxy（連線方式可以是虛 IP、域名、服務名等）。接下來就是 DBA 的工作，觀察流量，業務流量都切到 proxy 之後，切斷 Source 到 Target 的主從複製，確保資料一致之後，使用代理，將流量打到目的端資料庫。需要注意的是，在切流量和斷複製時，要保證時間足夠短，並且複製沒有延時。最後透過切換虛擬 ip 或修改 DNS 解析等，下掉 proxy，最終程式直接訪問目的端資料庫。或者通知業務在修改一次連線方式，從 proxy 到目的端資料庫。

總結一下遷移方案的優劣勢。

**優勢：**該方案的優勢在於，加入 proxy 之後，可以由 DBA 來控制入口流量的分發。開發在釋出程式修改連線方式時，支援滾動釋出，兩種訪問方式並存，不需要停服；另一方面，DBA 和開發工作解藕，不需要在某個固定時間釋出程式，進行割接，DBA 可以透過流量來源來判斷業務透過哪種方式來訪問資料庫，確保流量是否切乾淨。

**劣勢：**架構相對複雜，對 DBA 來說增加了運維成本和難度。業務中斷時間取決於 proxy 重啟時間，也就是將流量從 Source 叢集切到 Target 叢集的中斷時間，不過一般來說非常快，可以控制在秒級以內。資料庫連線會出現閃斷，需要確保業務能夠重連，同時還要保證主從資料的一致性。

2.3 小結

對比上面的兩種遷移方案，可以說各有千秋，有各自適用的場景，第一種方案比較適用於業務能夠接受中斷，資料庫叢集使用方比較明確，不存在多個業務混用情況，否則停機維護將會是一個巨大的工程。另一方面，需要業務方值得 信賴。

這裡信賴為什麼要加粗顯示呢？一定是有故事在其中。前面也說到，需要業務在特定的時間內，完成連線方式的修改，從老叢集地址修改到訪問新叢集。流量切換乾淨與否完全取決於業務方，在停服期間，DBA 沒有辦法判斷業務流量是否切換乾淨，是否還有殘餘的流量在老的叢集中寫入，只有業務啟動之後才能判斷。如果流量沒有切乾淨，那一切都晚了，業務開始雙寫，資料不一致了，想想怎麼回滾或者補資料去吧。但對於有“心機”的 DBA 來說，可能不那麼信任業務，會悄悄的留一手，透過老叢集設定只讀、回收使用者許可權等方式，讓業務沒法再往老叢集寫入。透過損失業務的方式來保證資料一致性，這樣下來，第二種方案優勢就非常明顯了。

第二種方案最核心的思想就在於讓資料庫可同時提供兩種訪問方式，兩種訪問方式同時指向一個數據庫例項，可以讓業務平滑的在兩種方式之間過渡。業務開發和 DBA 工作解藕，有充足的時間去釋出程式，DBA 也有相應的手段來判斷業務流量是否切徹底，確保資料一致。

3. Qunar 叢集架構

基於上述的第二種方案的思想，下面介紹 Qunar 內部架構升級遷移方案。先來了解下去哪兒網的資料庫架構。

3.1 MMM 叢集

叢集架構圖如下：

MMM（Master-Master replication manager for MySQL）是一套比較老的資料庫高可用架構了，早期在 Qunar 內部使用比較廣泛。採用 Monitor 和 Agent 來監控和管理 MySQL 的雙向複製。業務同一時刻只允許對一個主進行寫入，另一臺備選主上只提供讀服務，還可增加 Slave 節點，用於讀負載均衡，使用虛擬IP對外提供服務，不受客戶端的限制。

MMM 採用 VIP 漂移方式實現的故障轉移，由於使用的是非同步複製，無法完全的保證資料一致性，所以適用於對資料的一致性要求不是很高，但是又想最大程度的保證業務可用性的場景。對於那些對資料的一致性要求很高的業務，不建議採用 MMM 這種高可用架構，並且 MMM 不支援網路分割槽，無法實現跨機房部署。

詳細介紹請移步到官網：https://mysql-mmm.org

3.2 PXC 叢集

Percona XtraDB Cluster (簡稱 PXC) 是 Percona 公司開源的實現 MySQL 高可用的解決方案。它將 Percona Server 和 Percona XtraBackup 與 Galera 庫整合，以實現多主同步複製。和 MySQL 傳統的非同步複製相比，能夠保證資料的強一致性，在任何時刻叢集中任意節點上的資料狀態都是完全一致的，並且整個架構實現了去中心化，所有節點都是對等的，即允許在任意節點上進行寫入和讀取，叢集會把資料狀態同步至其他所有節點。但目前 PXC 叢集在使用上有較多限制，比如：只支援 InnoDB 儲存引擎，事務大小限制等等，需要選擇合適的應用場景。

詳細介紹請移步到官網：http://www.percona.com/doc/percona-xtradb-cluster

Qunar 內部使用架構圖如下：

Qunar 內部使用的 PXC 叢集一般為三節點，PXC 雖支援多點寫入，但多點寫入易導致資料衝突，會產生較大的額外開銷，影響效能，所以在生產環境中，我們仍然只在一個節點寫入，另外兩節點提供讀服務；只有在寫節點切換時，會允許短暫的多點寫入，以確保業務平滑的過渡到新的寫節點。PXC 高可用切換不同於傳統的主從切換，業務無需再忍受短暫的資料庫只讀和閃斷。以 namespace 服務名的方式對外服務，對業務層遮蔽的資料庫叢集節點真實的 ip 和埠，客戶端透過配置中心拿到叢集的拓撲資訊。

Sentinels： 哨兵叢集，用於監控 PXC 叢集的執行狀態和叢集拓撲資訊，類似於 Redis 的哨兵叢集，解決了 MMM Monitor 單點的問題； 當叢集拓撲結構發生變化，哨兵會修改配置中心，進行下線故障節點，提升主節點等操作； 同時修改 zookeeper 版本資訊，觸發客戶端重建連線，重新獲取叢集配置資訊。Config Server：叢集的配置中心，也是一套 PXC 叢集，用於儲存叢集的 namespace 和節點資訊（包括 ip，埠，讀寫角色，是否線上，變更資訊等）。

4. Qunar 叢集遷移 4.1 MMM 遷移 PXC

由於歷史原因，Qunar 資料庫內部還留存著較多 MMM 架構的叢集，一些比較重要的“祖傳”業務仍然在 MMM 上執行，揹負著較大的風險，一直沒出問題的，可以說是“運氣好”。最初 DBA 難以推動業務進行架構遷移，一是 PXC 架構業內使用較少，沒有足夠的瞭解，因此沒有信心；二是服務比較老且重要程度較高，不敢輕易變更。

經過 Qunar 多年的實踐檢驗，PXC 架構已經被證明是一套優秀的資料庫高可用解決方案。業務方開始有了一定的信任，加上今年疫情影響，我們開始”修煉內功“，藉助這個機會，DBA 部門向公司推行了 MMM 架構遷移 PXC 叢集計劃。

如此浩大的工程，需要有一個完備的解決方案，首先要具備以下幾點：

對業務友好，不停服，支援滾動釋出支援回滾，業務釋出一旦發現在 PXC 架構上執行有問題，可隨時回滾遷移週期長，整個過程必須保證高可用業務釋出不受時間限制，沒有固定視窗期

基於以上幾點，方案一就無法滿足了，因為老服務對資料庫複用情況嚴重，沒辦法一次性地將地址修改完全，也不可能接受長時間的停服。第二種方案，加一層 proxy，將 proxy 的 ip、埠註冊到 PXC 的配置中心，業務可以釋出到 namespace，實際還是透過 proxy 訪問老的叢集，流量指向實際還是由 proxy 來控制，並且配置中心支援人為觸發修改。

這樣看來，似乎可以滿足了上面的訴求。但問題也很明顯，DBA 需要多維護一套 proxy，並且還要保證 proxy 的高可用。此外，還會多出很多資源，我們要遷移的 MMM 叢集，共計120多套，維護成本和資源可想而知。

基於上述的遷移思想和 namespace 的特殊性，我們最終選擇了原地升級的方案，丟棄了 proxy 的代理。大致流程如下：

1、首先將 MMM 的 VIP 作為 PXC 叢集的訪問地址，註冊到配置中心和 zookeeper，提供可對外服務的 namespace。

2、通知業務釋出到 PXC 的 namespace；當業務透過 namespace 訪問資料庫時，實際還是透過 VIP 去訪問 MMM叢集節點。這個過程是支援隨時回滾的，同時支援 VIP 和 namespace 的訪問方式。具備高可用，對於 namespace 來說，下層是 VIP，會隨著 MMM 的高可用切換，因此不存在單點故障問題。

3、觀察業務流量切換情況，可透過 zk 連線進行判斷。

4、業務釋出完之後，逐個節點升級成 PXC 版本，部署哨兵完成完整 PXC 叢集的構建，升級過程如下：

下線 MMM 的備選主節點 MASTER2，升級為 PXC 的第一個節點。MASTER2 重新加入 MMM 叢集並恢復備選主的讀角色，進行讀寫角色切換，MASTER2 節點提升為主節點，對外提供服務（提供服務的節點為 PXC 版本，MMM 高可用依然有效，可以觀察一段時間，如果業務由於 PXC 的限制出現了相容性問題，可在這裡進行讀寫切換，寫角色切回到原先的普通版本）MMM 下線老的主節點 MASTER1（此時已作為備選主節點），並升級為 PXC 節點，以 MASTER2 作為 donor 組成2節點 PXC 叢集（此處 MMM 叢集的高可用已經被破壞，接下來的步驟需要連貫進行）。MMM 下線剩下的 SLAVE 節點，升級為 PXC 節點，加入到 MASTER1、MASTER2 組成的 PXC 叢集；部署哨兵叢集，修改配置中心 VIP 為實 IP，確認 VIP 沒有流量訪問，下線 VIP。

5、變更 zk 版本，通知客戶端重連。至此，業務已經完全遷移為 PXC 架構。

6、收尾工作，檢查監控、備份任務。

遷移過程需要注意的是，在逐個節點升級為 PXC 的過程中，升級到第二個節點之後，就已經破壞了 MMM 的高可用，而部署哨兵前 PXC 的高可用還未形成。所以到此環節時，需要快速而且連貫進行，我們使用自動化程序升級，確保操作的規範和高效，最大程度縮短了單點執行的時間和避免誤操作。極端情況下，也能手動繫結 VIP 確保服務的可用性。

上面的遷移方案已經通過了實踐的論證，並且得到開發同學的極力認可。目前去哪兒網內部已經完成超過70%的 MMM 叢集升級，整個流程實現了自動化，雖然遷移週期很長，但實際上不需要太多的人為干預。

4.2 遷移拆分案例

基於 MMM 原地升級 PXC 的思路，我們還可以應對很多遷移場景。現在業務有一個數據庫拆分的需求：叢集 A 為 MMM 叢集，由於上面的 DB 很多，業務混用多，而且流量大，資料庫已經不堪重負。現準備拆分一個比較重要的服務出來，對應例項裡的某一個 DB；要求獨立執行在新叢集上，需要支援跨機房部署，且由於業務的特殊性，服務不能中斷。

參考上述的遷移思路，我們來看看遷移架構圖：

原始叢集為 MMM 叢集，由 MASTER1 和 MASTER2 兩個節點構成，業務分別透過 WVip 和 RVip 進行訪問。現在業務 A 需要遷移出去，大致操作過程如下：

MMM 叢集的寫節點，MASTER1 作為 PXC 叢集的 donor 節點，搭建 PXC 叢集（前提是 MASTER1 已經由普通的 MySQL 版本，升級為 PXC 版本）。註冊 MASTER1 的實 IP 到配置中心；此時，MASTER1 支援使用 MMM-WVIP 和 PXC 的 namespace 訪問。需要遷移的業務可以平滑的從 WVip 過渡到 namespace。MMM 叢集 offline MASTER1，將 MASTER1 從 MMM 叢集脫離出來（此時 MMM 只有單點在提供服務，為確保可用性，可以提前增加從庫，避免極端的情況發生）。

遷移出來的業務已經訪問 PXC 叢集，而剩下的服務仍然訪問 MMM，剩下收尾工作就是把 MASTER1 從 PXC 叢集中下線，恢復 MMM 的備選主節點。

5. 總結

對於不同的資料庫架構、業務場景，選擇的遷移手段各有不同。除了同構資料庫遷移外，往往還會面臨各種異構資料庫遷移，那麼可能就需要藉助第三方工具才能實現資料遷移。總而言之，沒有最優秀的方案，只有最適合的方案。

本文主要闡述透過藉助代理層，使得同一個資料庫節點支援兩種方式或兩個地址訪問資料庫，讓業務流量能夠平滑的從老的連線方式過渡到新的連線方式，實現對業務最為友好的遷移方案。基於這種思想，我們可以應對多種遷移場景，不需要停服割接，並且將開發和 DBA 的工作解藕，很大程度上提升了工作效率。