網易雲 MySQL實例遷移的技術實現

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

咱們把數據庫裏部分或所有 Schema和數據遷移到另外一個實例的行爲稱爲實例遷移，將導出數據的實例稱爲源實例，導入數據的實例稱爲目標實例。

根據遷移數據庫類型的不一樣，能夠分爲同種數據庫之間的遷移，如從 MySQL遷到 MySQL；和跨數據庫類型的遷移，如從 Oracle遷移到 MySQL等。

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

使用場景

那麼，爲何要進行 MySQL實例遷移呢？不一樣場景下分別該如何遷移？實例遷移的場景概括起來主要有如下幾種：

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

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

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

二、從其餘公有云平臺遷移到 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.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經過遷移預檢查、提供出錯重試等措施來提升遷移成功率。

一、遷移評估和準備

用戶首先需在遷移前作好評估工做，包括選擇業務低峯期進行遷移，這樣既最小化對業務的影響同時也可以提升遷移速度；確認業務鏈接數據庫的配置可以進行一次性切換，縮短切換所需時間，同時避免部分業務邏輯鏈接源庫，另外一部分鏈接目標庫致使數據不一致；其次，根據所遷移的數據量，合理選擇目標實例的存儲空間，避免由於目標實例空間不足致使失敗；最後，還須要建立知足遷移要求的數據庫帳號。

二、預檢查

咱們但願在開始遷移前就發現全部可能引發遷移失敗的因素並糾正。遷移預檢查是重要手段，主要包括用戶在源實例建立的遷移 MySQL帳號權限檢查、MySQL參數設置檢查。

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

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

三、錯誤重試

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

遷移的每一個階段都會有帶進度條的百分比顯示，並週期性自動刷新。同時還會顯示總體的遷移進度，方便用戶隨時查看。若在數據導出或導入等階段發生錯誤，則會提示錯誤信息，通常出現遷移錯誤的緣由主要是因爲存在 MyISAM表致使持鎖時間超時，根據錯誤信息能夠對遷移參數進行鍼對性修改後進行重試，無需從新開始遷移。

四、結束遷移

在確認目標實例和源實例間沒有複製延遲後，就能夠結束遷移並將業務的 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...

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

文章來源： 網易雲社區