摘要：本文將介紹網易云基礎服務蜂巢實例遷移功能的實現，并探討如何高效完成實例遷移任務。網易云基礎服務蜂巢提供了負載監控閾值選項，在業務負載超過該閾值時，會暫停遷移操作，直到負載重新低于閾值。

歡迎訪問網易云社區，了解更多網易技術產品運營經驗。

我們把數據庫里部分或全部 Schema和數據遷移到另一個實例的行為稱為實例遷移，將導出數據的實例稱為源實例，導入數據的實例稱為目標實例。

根據遷移數據庫類型的不同，可以分為同種數據庫之間的遷移，如從 MySQL遷到 MySQL；和跨數據庫類型的遷移，如從 Oracle遷移到 MySQL等。

本文將介紹網易云基礎服務（蜂巢） RDS實例遷移功能的實現，并探討如何高效完成實例遷移任務。

使用場景

那么，為什么要進行 MySQL實例遷移呢？不同場景下分別該如何遷移？實例遷移的場景歸納起來主要有以下幾種：

1、從自建實例遷移到 RDS：

在云服務還未充分推廣時，存在大量自建數據庫實例，以網易公司為例，在公司業務全面上云之前，網易博客、網易郵箱等產品的數百個 MySQL實例都是直接部署在物理服務器上，而隨著業務的擴展，必然要對實例進行擴容、升規格等操作。

相比自建實例，RDS實例在故障處理、在線擴容、升級等方面存在著天然的優勢，所以，目前，網易絕大部分互聯網產品的數據庫均已使用實例遷移功能將實例遷移到了 RDS上；

2、從其他公有云平臺遷移到 RDS：

網易云基礎服務（蜂巢）RDS推出一年多的時間以來，有很多用戶將部署在其他公有云平臺上的 MySQL實例遷移到網易云基礎服務（蜂巢）RDS上。我們對實例遷移功能進行統計發現，有 50%是用于遷移其他公有云的 MySQL實例。

實例遷移技術實現

在設計實例遷移功能前，我們對業界公有云進行了充分調研，僅有兩家主流公有云平臺提供實例遷移功能，那么為什么僅兩家呢，主要是因為提供在線實例遷移功能需要解決一系列問題，概括起來有以下幾點：

1.如何快速地對源實例進行一致性數據備份？

2.如何處理備份過程中對源實例業務的影響？

3.如何快速地將備份導入到目標實例？

4.如何同步源實例的增量數據到目標實例？

5.如何確保實例遷移高效完成？

下面逐條解析網易云基礎服務（蜂巢） RDS是如何解決這些難題的。

1 多線程邏輯備份

我們解決第一個問題的方法是采用多線程邏輯備份的方式來進行源實例一致性數據導出。

MySQL的數據備份工具有很多，邏輯備份工具包括經典的 mysqlpump，MySQL 5.7版本新推出的 mysqlpump，Percona開源工具 mydumper；物理備份主要是 Percona的 xtrabackup工具。

俗話說沒有最好的，只有最合適的，那么在這些備份工具中，哪種工具最適合用于進行實例遷移呢？我們的答案是 mydumper。

首先我們排除了 xtrabackup，雖然物理備份在性能上有優勢，但其無法遠程備份源實例，在進行實例遷移時，我們不可能要求用戶賦予操作源實例服務器的權限，尤其在遷移其他公有云平臺的 RDS實例時更不現實。此外，物理備份產生的備份數據往往比邏輯備份導出的數據更大，因為 xtrabackup直接拷貝物理文件，而邏輯備份是導出 SQL語句。

下面是我們對幾種備份工具的對比測試結果，可供參考：

排除了物理備份后，還有三個選項：mysqldump、mysqlpump和 mydumper。我們最終選擇了 mydumper，因為 mydumper是多線程的。

等等！了解 MySQL的同學會質疑，mysqlpump也是多線程的啊？對，mysqlpump的多線程思想甚至比 mydumper更先進（詳見參考文獻1和2），但 mysqlpump是表級的并發，且還不成熟，而 mydumper是記錄級的并發，針對單個大表的場景，更容易發揮多線程優勢。

也許你會好奇，mydumper是如何實現記錄級的多線程一致性備份的，其備份流程圖如下：

mydumper由主線程和多個工作線程配合完成數據一致性備份，主線程執行 FTWRL或 Lock Tables tablelist Read阻塞寫操作來建立一致性備份點并記錄當前 BinLog和 GTID。工作線程在主線程仍持有鎖的情況下將各 session的事務級別設置為可重復讀（repeatable-read），并開始進行快照讀。由于此時各表無法進行數據寫入或更新，所以工作線程快照讀的數據就是主線程建立一致性備份點的數據。待所有工作線程均已開始快照讀后，如果不存在 MyISAM等非事務性表，主線程即可釋放讀鎖（mydumper原理的詳細分析詳見參考文獻3）。

2 業務負載監控與調整

無論是物理備份還是邏輯備份，都會或多或少地對數據庫線上業務造成影響。如何處理備份過程中對源實例業務的影響是我們需要解決的第二個問題。

網易云基礎服務（蜂巢） RDS實例的設計原則是線上業務永遠比遷移任務更重要。由于無法有效了解源實例所在服務器層的監控數據，我們在 MySQL數據庫層進行大量的優化來降低影響。包括引入持鎖時間超時機制、基于業務負載智能調整導出并發度和 InnoDB Buffer Pool（BP）污染控制等。

如前所述，為了能夠得到一致性的數據，各種備份工具，包括 xtrabackup和 mydumper，都需要有個短暫給源實例加讀鎖的過程，正常情況下短暫，但也會有例外，如源實例中存在數據量較大的 MyISAM表時，持鎖時間會變長。

為了能夠避免持鎖時間過長導致業務的寫操作被阻塞，使用網易云基礎服務（蜂巢） RDS進行實例遷移時，用戶可以選擇允許持有讀鎖的最長時間，如下圖所示，如果超過該閾值時間，會無條件解鎖并讓遷移操作失敗，用戶可以選擇在業務低峰期進行重試。

在順利加鎖建立一致性快照并解鎖后，就進入到各種 Schema和表數據的導出環節，用戶應根據源實例的線上業務負載和實例的服務器 IO能力來合理選擇導出數據的并發線程數，如上圖所示。

業務負載并不總是可以預測的，但業務總是最重要的，那么當短暫的業務高峰上來時，我們希望將服務器有限的 IO能力還給業務，而不是用在遷移上。網易云基礎服務（蜂巢） RDS提供了負載監控閾值選項，在業務負載超過該閾值時，會暫停遷移操作，直到負載重新低于閾值。如果用戶選擇了多線程導出，則能夠根據業務負載動態調整線程個數，確保在業務優先的前提下盡可能快速地完成數據導出操作。

下圖為基于業務負載自適應調整導出線程的例子。

在邏輯導出的過程中，還會根據用戶提供的遷移賬號權限，選擇性調整 InnoDB BP參數來最大限度減小遷移連接的查詢操作對 BP熱點數據的污染。盡可能將因遷移而進入 BP的數據保留在 BP的 LRU List冷數據一側，并盡快被替換出 BP（詳見參考文獻4）。當然，設置 BP的參數需要賬號有 Super權限，對于公有云上的源實例，無法進行該項優化。

3 多線程數據導入

使用與 mydumper配套的多線程恢復工具 myloader來將備份的數據導入到目標 RDS實例上，myloader執行流程如下圖所示。

由于此時目標實例沒有負載，所以可以盡可能調大導入并發線程數，將目標實例的 IO能力吃滿。此外，在數據導入時，我們通過關閉 slow log和 binary log，將 innodb_flush_log_at_trx_commit設置為 0來最大限度提高導入性能，在完成數據導入后再將對應的參數調整為原值。這是我們解決第三個問題的方法。

4 并行過濾復制

在完成數據導入后，對于全量遷移的場景，遷移就結束了。若選擇增量遷移，還需將數據導出和導入時在源實例上產生的增量數據（Update/Delete）也遷移到目標實例，我們采用 MySQL復制的方式來同步這些數據。

由于 MySQL 5.5、5.6和 5.7版本的復制存在較大差別，我們根據源實例的版本選擇對應的目標實例版本。對于 MySQL 5.5及更低版本的源實例，選擇網易開源 MySQL版本 InnoSQL 5.5.30作為目標 RDS實例版本，對于 MySQL 5.6和 5.7，選擇 InnoSQL 5.7.12為目標實例版本。進行上述版本配對的原因在于：

一是希望用戶盡可能采用 MySQL最新的穩定版本 5.7，因為 MySQL 5.7是有史以來最好的版本，帶來了眾多優秀的特性，包括基于 GTID的復制、sys表等，同時相比之前的版本，解決和優化了大量缺陷或不足。

二是能夠更加方便地配置復制。MySQL 5.7版本提供了基于 GTID和基于 BinLog兩套復制機制，針對源實例不同的復制配置，能無縫適配。用戶在遷移源實例時，可選擇遷移實例上全部數據庫，也可選擇僅遷移部分數據庫，MySQL 5.7版本可使用新增的 “CHANGE REPLICATION FILTER” 語法在線進行過濾復制設置而無需重啟 mysqld。

由于 MySQL 5.5及更低版本無法滿足 MySQL 5.7版本與之建立復制所需的實例 UUID，所以目標實例使用 InnoSQL 5.5.30版本。當然，相比社區版 MySQL 5.5.30，InnoSQL 5.5.30實現了在線過濾復制功能。

我們采用并行復制技術來提高增量數據同步的效率，快速縮短主從復制延遲。由于 MySQL 5.6版本 GTID特性并不完善，在將其遷移到 MySQL 5.7版本時，采用基于 DATABASE的并行復制方式，避免 LOGICAL_CLOCK并行復制時由于 GTID EVENT未記錄并行信息導致復制出錯的 bug。這樣，第四個問題也得到了解決。

如何高效完成遷移

相信大家都認同，實例遷移是個重型操作，誰都不會閑來無事對線上數據庫來一把實例遷移。既然決定要進行實例遷移，那么就希望能夠一次性完成遷移，避免來回折騰。

如何確保高效地遷移就顯得尤為重要，用戶需先進行遷移評估并完成準備工作，網易云基礎服務（蜂巢） RDS通過遷移預檢查、提供出錯重試等措施來提高遷移成功率。

1、遷移評估和準備

用戶首先需在遷移前做好評估工作，包括選擇業務低峰期進行遷移，這樣既最小化對業務的影響同時也能夠提高遷移速度；確認業務連接數據庫的配置能夠進行一次性切換，縮短切換所需時間，同時避免部分業務邏輯連接源庫，另一部分連接目標庫導致數據不一致；其次，根據所遷移的數據量，合理選擇目標實例的存儲空間，避免因為目標實例空間不足導致失敗；最后，還需要創建滿足遷移要求的數據庫賬號。

2、預檢查

我們希望在開始遷移前就發現所有可能引起遷移失敗的因素并糾正。遷移預檢查是重要手段，主要包括用戶在源實例創建的遷移 MySQL賬號權限檢查、MySQL參數設置檢查。

遷移權限檢查用于確認遷移賬號是否能夠順利完成遷移操作，主要包括對數據庫定義、表定義，視圖、觸發器、存儲過程和函數等 Schema的查看權限；對所選中數據庫中表的 Lock Table權限，及表中數據 Select權限；如果選擇增量遷移，則還需檢查賬號是否具備 Replication slave和 Replication client權限等。通過查詢源實例的 MySQL、information_schema或 performance_schema等系統庫來檢查遷移所需權限。

MySQL參數檢查主要針對需要做增量數據同步的場景，如果用戶選擇增量遷移，源實例需正確設置 server_id和 log_bin等參數。如果在預檢查中發現錯誤，會給出明確的提示，引導用戶進行參數調整后再重新進行預檢查。

3、錯誤重試

在遷移過程中，提供了進度顯示功能，如下所示：

遷移的每個階段都會有帶進度條的百分比顯示，并周期性自動刷新。同時還會顯示整體的遷移進度，方便用戶隨時查看。若在數據導出或導入等階段發生錯誤，則會提示錯誤信息，一般出現遷移錯誤的原因主要是由于存在 MyISAM表導致持鎖時間超時，根據錯誤信息可以對遷移參數進行針對性修改后進行重試，無需重新開始遷移。

4、結束遷移

在確認目標實例和源實例間沒有復制延遲后，就可以結束遷移并將業務的 IP切換為目標實例 IP。當然，在 IP切換前，請確認已經在網易云基礎服務（蜂巢） RDS實例上創建業務訪問所需的數據庫賬號并賦予合適的權限。

參考文獻：

http://www.innoMySQL.com/arti...
http://MySQLserverteam.com/in...
http://www.innoMySQL.com/arti...
http://dev.MySQL.com/doc/refm...
http://dev.MySQL.com/doc/refm...

網易云為您提供容器服務，歡迎點擊免費試用。

文章來源： 網易云社區