1. 程式人生 > >[原]不同場景下MySQL的遷移方案

[原]不同場景下MySQL的遷移方案

一 為什麼要遷移

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 的形式備份。和研發溝通後,形成一致的方案。

MySQL,遷移,方案
圖一 一主一從結構遷移從庫架構圖

具體做法是這樣:


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 充當從節點,架構圖如圖二。此次遷移只需要遷移指定庫,這些庫容量不是太大,並且可以保證資料不是實時的。

MySQL,遷移,方案
圖二 一主一從結構遷移指定庫架構圖

具體的做法如下:


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 的從節點,架構圖如圖三。此次遷移只需要遷移指定庫,這些庫容量不是太大,並且可以保證資料不是實時的。我們可以看到,此次遷移和場景二很類似,無非做了兩次遷移。

MySQL,遷移,方案
圖三 一主一從結構雙邊遷移指定庫架構圖

具體的做法如下:


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 充當從節點。遷移完成後,以前的主節點和從節點廢棄,架構圖如圖四。此次遷移是全庫遷移,容量大,並且需要保證實時。這次的遷移比較特殊,因為採取的策略是先替換新的從庫,再替換新的主庫。所以做法稍微複雜些。