不同場景下 MySQL 的遷移方案

一、為什麼要遷移

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

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

• 磁碟空間不夠。比如一些老專案，選用的機型並不一定適用於資料庫。隨著時間的推移，硬碟很有可能出現短缺；
• 業務出現瓶頸。比如專案中採用單機承擔所有的讀寫業務，業務壓力增大，不堪重負。如果 IO 壓力在可接受的範圍，會採用讀寫分離方案；
• 機器出現瓶頸。機器出現瓶頸主要在磁碟 IO 能力、記憶體、CPU，此時除了針對瓶頸做一些優化以外，選擇遷移是不錯的方案；
• 專案改造。某些專案的資料庫存在跨機房的情況，可能會在不同機房中增加節點，或者把機器從一個機房遷移到另一個機房。再比如，不同業務共用同一臺伺服器，為了緩解伺服器壓力以及方便維護，也會做遷移。

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

二、MySQL 遷移方案概覽

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

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

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

三、MySQL 遷移實戰

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

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

• 為了保護隱私，本文中的伺服器 IP 等資訊經過處理；
• 如果伺服器在同一機房，用伺服器 IP 的 D 段代替伺服器，具體的 IP 請參考架構圖；
• 如果伺服器在不同機房，用伺服器 IP 的 C 段 和 D 段代替伺服器，具體的 IP 請參考架構圖；
• 每個場景給出方法，但不會詳細地給出每一步執行什麼命令，因為一方面，這會導致文章過長；另一方面，我認為只要知道方法，具體的做法就會迎面撲來的，只取決於掌握知識的程度和獲取資訊的能力；
• 實戰過程中的注意事項請參考第五節。

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

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

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

具體做法是這樣：

• 研發將 102 的讀業務切到主庫；
• 確認 102 MySQL 狀態（主要看 PROCESS LIST），觀察機器流量，確認無誤後，停止 102 從節點的服務；
• 103 新建 MySQL 例項，建成以後，停止 MySQL 服務，並且將整個資料目錄 mv 到其他地方做備份；
• 將 102 的整個 mysql 資料目錄使用 rsync 拷貝到 103；
• 拷貝的同時，在 101 授權，使 103 有拉取 binlog 的許可權（REPLICATION SLAVE, REPLICATION CLIENT）；
• 待拷貝完成，修改 103 配置檔案中的 server_id，注意不要和 102 上的一致；
• 在 103 啟動 MySQL 例項，注意配置檔案中的資料檔案路徑以及資料目錄的許可權；
• 進入 103 MySQL 例項，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；
• Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 101 和 103 的資料一致，但比較耗時，而且對主節點有影響，可以和開發一起進行資料一致性的驗證；
• 和研發溝通，除了做資料一致性驗證外，還需要驗證賬號許可權，以防業務遷回後訪問出錯；
• 做完上述步驟，可以和研發協調，把 101 的部分讀業務切到 103，觀察業務狀態；
• 如果業務沒有問題，證明遷移成功。

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

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

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

具體的做法如下：

• 103 和 104 新建例項，搭建主從關係，此時的主節點和從節點處於空載；
• 102 匯出資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；
• 102 收集指定庫需要的賬號以及許可權；
• 102 匯出資料完畢，使用 rsync 傳輸到 103，必要時做壓縮操作；
• 103 匯入資料，此時資料會自動同步到 104，監控伺服器狀態以及 MySQL 狀態；
• 103 匯入完成，104 同步完成，103 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；
• 上述完成後，可研發協作，將 101 和 102 的業務遷移到 103 和 104，觀察業務狀態；
• 如果業務沒有問題，證明遷移成功。

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

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

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

具體的做法如下：

• 103 和 104 新建例項，搭建主從關係，此時的主節點和從節點處於空載；
• 102 匯出 103 需要的指定庫資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；
• 102 收集 103 需要的指定庫需要的賬號以及許可權；
• 102 匯出103 需要的指定庫資料完畢，使用 rsync 傳輸到 103，必要時做壓縮操作；
• 103 匯入資料，此時資料會自動同步到 104，監控伺服器狀態以及 MySQL 狀態；
• 103 匯入完成，104 同步完成，103 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；
• 上述完成後，和研發協作，將 101 和 102 的業務遷移到 103 和 104，觀察業務狀態；
• 105 和 106 新建例項，搭建主從關係，此時的主節點和從節點處於空載；
• 102 匯出 105 需要的指定庫資料，正確的做法是配置定時任務，在業務低峰做匯出操作，此處選擇的是 mysqldump；
• 102 收集 105 需要的指定庫需要的賬號以及許可權；
• 102 匯出 105 需要的指定庫資料完畢，使用 rsync 傳輸到 105，必要時做壓縮操作；
• 105 匯入資料，此時資料會自動同步到 106，監控伺服器狀態以及 MySQL 狀態；
• 105 匯入完成，106 同步完成，105 根據 102 收集的賬號授權，完成後，通知研發檢查資料以及賬戶許可權；
• 上述完成後，和研發協作，將 101 和 102 的業務遷移到 105 和 106，觀察業務狀態；
• 如果所有業務沒有問題，證明遷移成功。

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

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

圖四 一主一從結構完整遷移主從架構圖

具體的做法是這樣：

• 研發將 102 的讀業務切到主庫；
• 確認 102 MySQL 狀態（主要看 PROCESS LIST，MASTER STATUS），觀察機器流量，確認無誤後，停止 102 從節點的服務；
• 104 新建 MySQL 例項，建成以後，停止 MySQL 服務，並且將整個資料目錄 mv 到其他地方做備份，注意，此處操作的是 104，也就是未來的從庫；
• 將 102 的整個 mysql 資料目錄使用 rsync 拷貝到 104；
• 拷貝的同時，在 101 授權，使 104 有拉取 binlog 的許可權（REPLICATION SLAVE, REPLICATION CLIENT）；
• 待拷貝完成，修改 104 配置檔案中的 server_id，注意不要和 102 上的一致；
• 在 104 啟動 MySQL 例項，注意配置檔案中的資料檔案路徑以及資料目錄的許可權；
• 進入 104 MySQL 例項，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；
• Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 101 和 104 的資料一致，但比較耗時，而且對主節點有影響，可以和開發一起進行資料一致性的驗證；
• 除了做資料一致性驗證外，還需要驗證賬號許可權，以防業務遷走後訪問出錯；
• 和研發協作，將之前 102 從節點的讀業務切到 104；
• 利用 102 的資料，將 103 變為 101 的從節點，方法同上；
• 接下來到了關鍵的地方了，我們需要把 104 變成 103 的從庫；

1. 104 STOP SLAVE；
2. 103 STOP SLAVE IO_THREAD;
3. 103 STOP SLAVE SQL_THREAD，記住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
4. 104 START SLAVE UNTIL 到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS；
5. 104 再次 STOP SLAVE；
6. 104 RESET SLAVE ALL 清除從庫配置資訊；
7. 103 SHOW MASTER STATUS，記住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
8. 103 授權給 104 訪問 binlog 的許可權；
9. 104 CHANGE MASTER TO 103；
10. 104 重啟 MySQL，因為 RESET SLAVE ALL 後，檢視 SLAVE STATUS，Master_Server_Id 仍然為 101，而不是 103；
11. 104 MySQL 重啟後，SLAVE 回自動重啟，此時檢視 IO_THREAD 和 SQL_THREAD 是否為 YES；
12. 103 START SLAVE；
13. 此時檢視 103 和 104 的狀態，可以發現，以前 104 是 101 的從節點，如今變成 103 的從節點了。

• 業務遷移之前，斷掉 103 和 101 的同步關係；
• 做完上述步驟，可以和研發協調，把 101 的讀寫業務切回 102，讀業務切到 104。需要注意的是，此時 101 和 103 均可以寫，需要保證 101 在沒有寫入的情況下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 鎖住 101，然後業務切到 103。注意，一定要業務低峰執行，切記；
• 切換完成後，觀察業務狀態；
• 如果業務沒有問題，證明遷移成功。

3.5 場景五 雙主結構跨機房遷移

接下來看看雙主結構跨機房遷移怎麼做。某專案出於容災考慮，使用了跨機房，採用了雙主結構，雙邊均可以寫。因為磁碟空間問題，需要對 A 地的機器進行替換。打算將主節點 1.101 和從節點 1.102 同時遷移至新的機器 1.103 和 1.104，1.103 充當主節點，1.104 充當從節點。B 地的 2.101 和 2.102 保持不變，但遷移完成後，1.103 和 2.101 互為雙主。架構圖如圖五。因為是雙主結構，兩邊同時寫，如果要替換主節點，單方必須有節點停止服務。

圖五 雙主結構跨機房遷移架構圖

具體的做法如下：

• 1.103 和 1.104 新建例項，搭建主從關係，此時的主節點和從節點處於空載；
• 確認 1.102 MySQL 狀態（主要看 PROCESS LIST），注意觀察 MASTER STATUS 不再變化。觀察機器流量，確認無誤後，停止 1.102 從節點的服務；
• 1.103 新建 MySQL 例項，建成以後，停止 MySQL 服務，並且將整個資料目錄 mv 到其他地方做備份；
• 將 1.102 的整個 mysql 資料目錄使用 rsync 拷貝到 1.103；
• 拷貝的同時，在 1.101 授權，使 1.103 有拉取 binlog 的許可權（REPLICATION SLAVE, REPLICATION CLIENT）；
• 待拷貝完成，修改 1.103 配置檔案中的 server_id，注意不要和 1.102 上的一致；
• 在 1.103 啟動 MySQL 例項，注意配置檔案中的資料檔案路徑以及資料目錄的許可權；
• 進入 1.103 MySQL 例項，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；
• Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 1.101 和 1.103 的資料一致，但比較耗時，而且對主節點有影響，可以和開發一起進行資料一致性的驗證；
• 我們使用相同的辦法，使 1.104 變成 1.103 的從庫；
• 和研發溝通，除了做資料一致性驗證外，還需要驗證賬號許可權，以防業務遷走後訪問出錯；
• 此時，我們要做的就是將 1.103 變成 2.101 的從庫，具體的做法可以參考場景四；
• 需要注意的是，1.103 的單雙號配置需要和 1.101 一致；
• 做完上述步驟，可以和研發協調，把 1.101 的讀寫業務切到 1.103，把 1.102 的讀業務切到 1.104。觀察業務狀態；
• 如果業務沒有問題，證明遷移成功。

3.6 場景六 多例項跨機房遷移

接下來我們看看多例項跨機房遷移證明做。每臺機器的例項關係，我們可以參考圖六。此次遷移的目的是為了做資料修復。在 2.117 上建立 7938 和 7939 例項，替換之前資料異常的例項。因為業務的原因，某些庫只在 A 地寫，某些庫只在 B 地寫，所以存在同步過濾的情況。

圖六 多例項跨機房遷移架構圖

具體的做法如下：

• 1.113 針對 7936 例項使用 innobackupex 做資料備份，注意需要指定資料庫，並且加上 slave-info 引數；
• 備份完成後，將壓縮檔案拷貝到 2.117；
• 2.117 建立資料目錄以及配置檔案涉及的相關目錄；
• 2.117 使用 innobackupex 恢復日誌；
• 2.117 使用 innobackupex 拷貝資料；
• 2.117 修改配置檔案，注意如下引數：replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id；
• 2.117 更改資料目錄許可權；
• 1.112 授權，使 2.117 有拉取 binlog 的許可權（REPLICATION SLAVE, REPLICATION CLIENT）；
• 2.117 CHANGE MASTE TO 1.112，LOG FILE 和 LOG POS 參考 xtrabackup_slave_info；
• 2.117 START SLAVE，檢視從庫狀態；
• 2.117 上建立 7939 的方法類似，不過配置檔案需要指定 replicate-wild-do-table；
• 和開發一起進行資料一致性的驗證和驗證賬號許可權，以防業務遷走後訪問出錯；
• 做完上述步驟，可以和研發協調，把相應業務遷移到 2.117 的 7938 例項和 7939 例項。觀察業務狀態；
• 如果業務沒有問題，證明遷移成功。

四 注意事項

介紹完不同場景的遷移方案，需要注意如下幾點：

• 資料庫遷移，如果涉及事件，記住主節點開啟 event_scheduler 引數；
• 不管什麼場景下的遷移，都要隨時關注伺服器狀態，比如磁碟空間，網路抖動；另外，對業務的持續監控也是必不可少的；
• CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切記不要找錯，如果指定錯了，帶來的後果就是資料不一致或者搭建主從關係失敗；
• 執行指令碼不要在 $HOME 目錄，記住在資料目錄；
• 遷移工作可以使用指令碼做到自動化，但不要弄巧成拙，任何指令碼都要經過測試；
• 每執行一條命令都要三思和後行，每個命令的引數含義都要搞明白；
• 多例項環境下，關閉 MySQL 採用 mysqladmin 的形式，不要把正在使用的例項關閉了；
• 從庫記得把 read_only = 1 加上，這會避免很多問題；
• 每臺機器的 server_id 必須保證不一致，否則會出現同步異常的情況；
• 正確配置 replicate-ignore-db 和 replicate-wild-do-table；
• 新建的例項記得把 innodb_file_per_table 設定為 1，上述中的部分場景，因為之前的例項此引數為 0，導致 ibdata1 過大，備份和傳輸都消耗了很多時間；
• 使用 gzip 壓縮資料時，注意壓縮完成後，gzip 會把原始檔刪除；
• 所有的操作務必在從節點或者備節點操作，如果在主節點操作，主節點很可能會當機；
• xtrabackup 備份不會鎖定 InnoDB 表，但會鎖定 MyISAM 表。所以，操作之前記得檢查下當前資料庫的表是否有使用 MyISAM 儲存引擎的，如果有，要麼單獨處理，要麼更改表的 Engine。

五 技巧

在 MySQL 遷移實戰中，有如下技巧可以使用：

• 任何遷移 LOG FILE 以 relay_master_log_file（正在同步 master 上的 binlog 日誌名）為準，LOG POS 以 exec_master_log_pos（正在同步當前 binlog 日誌的 POS 點）為準；
• 使用 rsync 拷貝資料，可以結合 expect、nohup 使用，絕對是絕妙組合；
• 在使用 innobackupex 備份資料的同時可以使用 gzip 進行壓縮；
• 在使用 innobackupex 備份資料，可以加上 –slave-info 引數，方便做從庫；
• 在使用 innobackupex 備份資料，可以加上 –Throttle 引數，限制 IO，減少對業務的影響。還可以加上 –parallel=n 引數，加快備份，但需要注意的是，使用 tar 流壓縮，–parallel 引數無效；
• 做資料的備份與恢復，可以把待辦事項列個清單，畫個流程，然後把需要執行的命令提前準備好；
• 本地快速拷貝資料夾，有個不錯的方法，使用 rsync，加上如下引數：-avhW –no-compress –progress；
• 不同分割槽之間快速拷貝資料，可以使用 dd。或者用一個更靠譜的方法，備份到硬碟，然後放到伺服器上。異地還有更絕的，直接快遞硬碟。

六 總結

本文從為什麼要遷移講起，接下來講了遷移方案，然後講解了不同場景下的遷移實戰，最後給出了注意事項以及實戰技巧。歸納起來，也就以下幾點：

第一，遷移的目的是讓業務平穩持續地執行；
第二，遷移的核心是怎麼延續主從同步，我們需要在不同伺服器和不同業務之間找到方案；
第三，業務切換需要考慮不同 MySQL 伺服器之間的許可權問題；需要考慮不同機器讀寫分離的順序以及主從關係；需要考慮跨機房呼叫對業務的影響。

讀者在實施遷移的過程中，可以參考此文提供的思路。但怎樣保證每個操作正確無誤地執行，還需要三思而後行。

說句題外話，「證明自己有能力最重要的一點就是讓一切都在自己的掌控之中。」