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

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運營經(jīng)驗。

我們把數(shù)據(jù)庫里部分或全部 Schema和數(shù)據(jù)遷移到另一個實例的行為稱為實例遷移，將導(dǎo)出數(shù)據(jù)的實例稱為源實例，導(dǎo)入數(shù)據(jù)的實例稱為目標(biāo)實例。

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

本文將介紹網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢） RDS實例遷移功能的實現(xiàn)，并探討如何高效完成實例遷移任務(wù)。

使用場景

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

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

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

相比自建實例，RDS實例在故障處理、在線擴(kuò)容、升級等方面存在著天然的優(yōu)勢，所以，目前，網(wǎng)易絕大部分互聯(lián)網(wǎng)產(chǎn)品的數(shù)據(jù)庫均已使用實例遷移功能將實例遷移到了 RDS上；

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

網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢）RDS推出一年多的時間以來，有很多用戶將部署在其他公有云平臺上的 MySQL實例遷移到網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢）RDS上。我們對實例遷移功能進(jìn)行統(tǒng)計發(fā)現(xiàn)，有 50%是用于遷移其他公有云的 MySQL實例。

實例遷移技術(shù)實現(xiàn)

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

1.如何快速地對源實例進(jìn)行一致性數(shù)據(jù)備份？

2.如何處理備份過程中對源實例業(yè)務(wù)的影響？

3.如何快速地將備份導(dǎo)入到目標(biāo)實例？

4.如何同步源實例的增量數(shù)據(jù)到目標(biāo)實例？

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

下面逐條解析網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢） RDS是如何解決這些難題的。

1 多線程邏輯備份

我們解決第一個問題的方法是采用多線程邏輯備份的方式來進(jìn)行源實例一致性數(shù)據(jù)導(dǎo)出。

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

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

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

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

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

等等！了解 MySQL的同學(xué)會質(zhì)疑，mysqlpump也是多線程的??？對，mysqlpump的多線程思想甚至比 mydumper更先進(jìn)（詳見參考文獻(xiàn)1和2），但 mysqlpump是表級的并發(fā)，且還不成熟，而 mydumper是記錄級的并發(fā)，針對單個大表的場景，更容易發(fā)揮多線程優(yōu)勢。

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

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

2 業(yè)務(wù)負(fù)載監(jiān)控與調(diào)整

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

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

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

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

在順利加鎖建立一致性快照并解鎖后，就進(jìn)入到各種 Schema和表數(shù)據(jù)的導(dǎo)出環(huán)節(jié)，用戶應(yīng)根據(jù)源實例的線上業(yè)務(wù)負(fù)載和實例的服務(wù)器 IO能力來合理選擇導(dǎo)出數(shù)據(jù)的并發(fā)線程數(shù)，如上圖所示。

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

下圖為基于業(yè)務(wù)負(fù)載自適應(yīng)調(diào)整導(dǎo)出線程的例子。

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

3 多線程數(shù)據(jù)導(dǎo)入

使用與 mydumper配套的多線程恢復(fù)工具 myloader來將備份的數(shù)據(jù)導(dǎo)入到目標(biāo) RDS實例上，myloader執(zhí)行流程如下圖所示。

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

4 并行過濾復(fù)制

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

由于 MySQL 5.5、5.6和 5.7版本的復(fù)制存在較大差別，我們根據(jù)源實例的版本選擇對應(yīng)的目標(biāo)實例版本。對于 MySQL 5.5及更低版本的源實例，選擇網(wǎng)易開源 MySQL版本 InnoSQL 5.5.30作為目標(biāo) RDS實例版本，對于 MySQL 5.6和 5.7，選擇 InnoSQL 5.7.12為目標(biāo)實例版本。進(jìn)行上述版本配對的原因在于：

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

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

由于 MySQL 5.5及更低版本無法滿足 MySQL 5.7版本與之建立復(fù)制所需的實例 UUID，所以目標(biāo)實例使用 InnoSQL 5.5.30版本。當(dāng)然，相比社區(qū)版 MySQL 5.5.30，InnoSQL 5.5.30實現(xiàn)了在線過濾復(fù)制功能。

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

如何高效完成遷移

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

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

1、遷移評估和準(zhǔn)備

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

2、預(yù)檢查

我們希望在開始遷移前就發(fā)現(xiàn)所有可能引起遷移失敗的因素并糾正。遷移預(yù)檢查是重要手段，主要包括用戶在源實例創(chuàng)建的遷移 MySQL賬號權(quán)限檢查、MySQL參數(shù)設(shè)置檢查。

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

MySQL參數(shù)檢查主要針對需要做增量數(shù)據(jù)同步的場景，如果用戶選擇增量遷移，源實例需正確設(shè)置 server_id和 log_bin等參數(shù)。如果在預(yù)檢查中發(fā)現(xiàn)錯誤，會給出明確的提示，引導(dǎo)用戶進(jìn)行參數(shù)調(diào)整后再重新進(jìn)行預(yù)檢查。

3、錯誤重試

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

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

4、結(jié)束遷移

在確認(rèn)目標(biāo)實例和源實例間沒有復(fù)制延遲后，就可以結(jié)束遷移并將業(yè)務(wù)的 IP切換為目標(biāo)實例 IP。當(dāng)然，在 IP切換前，請確認(rèn)已經(jīng)在網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢） RDS實例上創(chuàng)建業(yè)務(wù)訪問所需的數(shù)據(jù)庫賬號并賦予合適的權(quán)限。

參考文獻(xiàn)：

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...

網(wǎng)易云為您提供容器服務(wù)，歡迎點擊免費試用。

文章來源： 網(wǎng)易云社區(qū)