一 為什麼要遷移

MySQL 遷移是 DBA 日常維護中的一個工作。遷移，究其本義，無非是把實際存在的物體挪走，保證該物體的完整性以及延續性。就像柔軟的沙灘上，兩個天真無邪的小孩，把一堆沙子挪向其他地方，鑄就內心神往的城堡。

生產環境中，有以下情況需要做遷移工作，如下：

1.磁碟空間不夠。比如一些老專案，選用的機型並不一定適用於資料庫。隨著時間的推移，硬碟很有可能出現短缺；

2.業務出現瓶頸。比如專案中採用單機承擔所有的讀寫業務，業務壓力增大，不堪重負。如果 IO 壓力在可接受的範圍，會採用讀寫分離方案；

3.機器出現瓶頸。機器出現瓶頸主要在磁碟 IO 能力、記憶體、CPU，此時除了針對瓶頸做一些優化以外，選擇遷移是不錯的方案；

4.專案改造。某些專案的資料庫存在跨機房的情況，可能會在不同機房中增加節點，或者把機器從一個機房遷移到另一個機房。再比如，不同業務共用同一臺伺服器，為了緩解伺服器壓力以及方便維護，也會做遷移。

一句話，遷移工作是不得已而為之。實施遷移工作，目的是讓業務平穩持續地執行。

二 MySQL 遷移方案概覽

MySQL 遷移無非是圍繞著資料做工作，再繼續延伸，無非就是在保證業務平穩持續地執行的前提下做備份恢復。那問題就在怎麼快速安全地進行備份恢復。

一方面，備份。針對每個主節點的從節點或者備節點，都有備份。這個備份可能是全備，可能是增量備份。線上備份的方法，可能是使用 mysqldump，可能是 xtrabackup，還可能是 mydumper。針對小容量（10GB 以下）資料庫的備份，我們可以使用 mysqldump。但針對大容量資料庫（數百GB 或者 TB 級別），我們不能使用 mysqldump 備份，一方面，會產生鎖；另一方面，耗時太長。這種情況，可以選擇 xtrabackup 或者直接拷貝資料目錄。直接拷貝資料目錄方法，不同機器傳輸可以使用 rsync，耗時跟網路相關。使用 xtrabackup，耗時主要在備份和網路傳輸。如果有全備或者指定庫的備份檔案，這是獲取備份的最好方法。如果備庫可以容許停止服務，直接拷貝資料目錄是最快的方法。如果備庫不允許停止服務，我們可以使用 xtrabackup（不會鎖定 InnoDB 表），這是完成備份的最佳折中辦法。

另一方面，恢復。針對小容量（10GB 以下）資料庫的備份檔案，我們可以直接匯入。針對大容量資料庫（數百GB 或者 TB 級別）的恢復，拿到備份檔案到本機以後，恢復不算困難。具體的恢復方法可以參考第四節。

三 MySQL 遷移實戰

我們搞明白為什麼要做遷移，以及遷移怎麼做以後，接下來看看生產環境是怎樣操作的。不同的應用場景，有不同的解決方案。

閱讀具體的實戰之前，假設和讀者有如下約定：

1.為了保護隱私，本文中的伺服器 IP 等資訊經過處理；

2.如果伺服器在同一機房，用伺服器 IP 的 D 段代替伺服器，具體的 IP 請參考架構圖；

3.如果伺服器在不同機房，用伺服器 IP 的 C 段 和 D 段代替伺服器，具體的 IP 請參考架構圖；

4.每個場景給出方法，但不會詳細地給出每一步執行什麼命令，因為一方面，這會導致文章過長；另一方面，我認為只要知道方法，具體的做法就會迎面撲來的，只取決於掌握知識的程度和獲取資訊的能力；

5.實戰過程中的注意事項請參考第五節。

3.1 場景一 一主一從結構遷移從庫

遵循從易到難的思路，我們從簡單的結構入手。A 專案，原本是一主一從結構。101 是主節點，102 是從節點。因業務需要，把 102 從節點遷移至 103，架構圖如圖一。102 從節點的資料容量過大，不能使用 mysqldump 的形式備份。和研發溝通後，形成一致的方案。

圖一 一主一從結構遷移從庫架構圖

具體做法是這樣：

1.研發將 102 的讀業務切到主庫；

2.確認 102 MySQL 狀態（主要看 PROCESS LIST），觀察機器流量，確認無誤後，停止 102 從節點的服務；

3.103 新建 MySQL 例項，建成以後，停止 MySQL 服務，並且將整個資料目錄 mv 到其他地方做備份；

4.將 102 的整個 mysql 資料目錄使用 rsync 拷貝到 103；

5.拷貝的同時，在 101 授權，使 103 有拉取  binlog 的許可權（REPLICATION SLAVE, REPLICATION CLIENT）；

6.待拷貝完成，修改 103 配置檔案中的 server_id，注意不要和 102 上的一致；

7.在 103 啟動 MySQL 例項，注意配置檔案中的資料檔案路徑以及資料目錄的許可權；

8.進入 103 MySQL 例項，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；

9.Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 101 和 103 的資料一致，但比較耗時，而且對主節點有影響，可以和開發一起進行資料一致性的驗證；

10.和研發溝通，除了做資料一致性驗證外，還需要驗證賬號許可權，以防業務遷回後訪問出錯；

11.做完上述步驟，可以和研發協調，把 101 的部分讀業務切到 103，觀察業務狀態；

12.如果業務沒有問題，證明遷移成功。

3.2 場景二 一主一從結構遷移指定庫

我們知道一主一從只遷移從庫怎麼做之後，接下來看看怎樣同時遷移主從節點。因不同業務同時訪問同一伺服器，導致單個庫壓力過大，還不便管理。於是，打算將主節點 101 和從節點 102 同時遷移至新的機器 103 和 104，103 充當主節點，104 充當從節點，架構圖如圖二。此次遷移只需要遷移指定庫，這些庫容量不是太大，並且可以保證資料不是實時的。

圖二 一主一從結構遷移指定庫架構圖

具體的做法如下：

1、103 和 104 新建例項，搭建主從關係，此時的主節點和從節點處於空載；

2、102 匯出資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；

3、102 收集指定庫需要的賬號以及許可權；

4、102 匯出資料完畢，使用 rsync 傳輸到 103，必要時做壓縮操作；

5、103 匯入資料，此時資料會自動同步到 104，監控伺服器狀態以及 MySQL 狀態；

6、103 匯入完成，104 同步完成，103 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；

7、上述完成後，可研發協作，將 101 和 102 的業務遷移到 103 和 104，觀察業務狀態；

8、如果業務沒有問題，證明遷移成功。

3.3 場景三 一主一從結構雙邊遷移指定庫

接下來看看一主一從結構雙邊遷移指定庫怎麼做。同樣是因為業務共用，導致伺服器壓力大，管理混亂。於是，打算將主節點 101 和從節點 102 同時遷移至新的機器 103、104、105、106，103 充當 104 的主節點，104 充當 103 的從節點，105 充當 106 的主節點，106 充當 105 的從節點，架構圖如圖三。此次遷移只需要遷移指定庫，這些庫容量不是太大，並且可以保證資料不是實時的。我們可以看到，此次遷移和場景二很類似，無非做了兩次遷移。

圖三 一主一從結構雙邊遷移指定庫架構圖

具體的做法如下：

1、103 和 104 新建例項，搭建主從關係，此時的主節點和從節點處於空載；

2、102 匯出 103 需要的指定庫資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；

3、102 收集 103 需要的指定庫需要的賬號以及許可權；

4、102 匯出103 需要的指定庫資料完畢，使用 rsync 傳輸到 103，必要時做壓縮操作；

5、103 匯入資料，此時資料會自動同步到 104，監控伺服器狀態以及 MySQL 狀態；

6、103 匯入完成，104 同步完成，103 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；

7、上述完成後，和研發協作，將 101 和 102 的業務遷移到 103 和 104，觀察業務狀態；

8、105 和 106 新建例項，搭建主從關係，此時的主節點和從節點處於空載；

9、102 匯出 105 需要的指定庫資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；

10、102 收集 105 需要的指定庫需要的賬號以及許可權；

11、102 匯出 105 需要的指定庫資料完畢，使用 rsync 傳輸到 105，必要時做壓縮操作；

12、105 匯入資料，此時資料會自動同步到 106，監控伺服器狀態以及 MySQL 狀態；

13、105 匯入完成，106 同步完成，105 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；

14、上述完成後，和研發協作，將 101 和 102 的業務遷移到 105 和 106，觀察業務狀態；

15、如果所有業務沒有問題，證明遷移成功。

3.4 場景四 一主一從結構完整遷移主從

接下來看看一主一從結構完整遷移主從怎麼做。和場景二類似，不過此處是遷移所有庫。因 101 主節點 IO 出現瓶頸，打算將主節點 101 和從節點 102 同時遷移至新的機器 103 和 104，103 充當主節點，104 充當從節點。遷移完成後，以前的主節點和從節點廢棄，架構圖如圖四。此次遷移是全庫遷移，容量大，並且需要保證實時。這次的遷移比較特殊，因為採取的策略是先替換新的從庫，再替換新的主庫。所以做法稍微複雜些。