[原]不一樣場景下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 的形式備份。和研發溝通後，造成一致的方案。

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

 

具體作法是這樣：

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 充當從節點，架構圖如圖二。這次遷移只須要遷移指定庫，這些庫容量不是太大，而且能夠保證數據不是實時的。

 

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

 

具體的作法以下：

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

二、102 導出數據，正確的作法是配置定時任務，在業務低峯作導出操做，此處選擇的是 mysqldump；

三、102 收集指定庫須要的帳號以及權限；

四、102 導出數據完畢，使用 rsync 傳輸到 103，必要時作壓縮操做；

五、103 導入數據，此時數據會自動同步到 104，監控服務器狀態以及 MySQL 狀態；

六、103 導入完成，104 同步完成，103 根據 102 收集的帳號受權，完成後，通知研發檢查數據以及帳戶權限；

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

八、若是業務沒有問題，證實遷移成功。

 

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

 

接下來看看一主一從結構雙邊遷移指定庫怎麼作。一樣是由於業務共用，致使服務器壓力大，管理混亂。因而，打算將主節點 101 和從節點 102 同時遷移至新的機器 10三、10四、10五、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 狀態；

1三、105 導入完成，106 同步完成，105 根據 102 收集的帳號受權，完成後，通知研發檢查數據以及帳戶權限；

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

1五、若是全部業務沒有問題，證實遷移成功。

 

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 的從節點，方法同上；

1三、接下來到了關鍵的地方了，咱們須要把 104 變成 103 的從庫；

- 104 STOP SLAVE；
- 103 STOP SLAVE IO_THREAD;
- 103 STOP SLAVE SQL_THREAD，記住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
- 104 START SLAVE UNTIL到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS；
- 104 再次 STOP SLAVE；
- 104 RESET SLAVE ALL 清除從庫配置信息；
- 103 SHOW MASTER STATUS，記住 MASTER_LOG_FILE 和 MASTER_LOG_POS；
- 103 受權給 104 訪問 binlog 的權限；
- 104 CHANGE MASTER TO 103；
- 104 重啓 MySQL，由於 RESET SLAVE ALL 後，查看 SLAVE STATUS，Master_Server_Id 仍然爲 101，而不是 103；
- 104 MySQL 重啓後，SLAVE 回自動重啓，此時查看 IO_THREAD 和 SQL_THREAD 是否爲 YES；
- 103 START SLAVE；
- 此時查看 103 和 104 的狀態，能夠發現，之前 104 是 101 的從節點，現在變成 103 的從節點了。

1四、業務遷移以前，斷掉 103 和 101 的同步關係；

1五、作完上述步驟，能夠和研發協調，把 101 的讀寫業務切回 102，讀業務切到 104。須要注意的是，此時 101 和 103 都可以寫，須要保證 101 在沒有寫入的狀況下切到 103，可使用 FLUSH TABLES WITH READ LOCK 鎖住 101，而後業務切到 103。注意，必定要業務低峯執行，切記；

1六、切換完成後，觀察業務狀態；

1七、若是業務沒有問題，證實遷移成功。

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三、須要注意的是，1.103 的單雙號配置須要和 1.101 一致；

1四、作完上述步驟，能夠和研發協調，把 1.101 的讀寫業務切到 1.103，把 1.102 的讀業務切到 1.104。觀察業務狀態；

1五、若是業務沒有問題，證實遷移成功。

 

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 = 一、read_only = 一、 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；

十二、和開發一塊兒進行數據一致性的驗證和驗證帳號權限，以防業務遷走後訪問出錯；

1三、作完上述步驟，能夠和研發協調，把相應業務遷移到 2.117 的 7938 實例和 7939 實例。觀察業務狀態；

1四、若是業務沒有問題，證實遷移成功。

 

四 注意事項

 

介紹完不一樣場景的遷移方案，須要注意以下幾點：

 

一、數據庫遷移，若是涉及事件，記住主節點打開 event_scheduler 參數；

二、無論什麼場景下的遷移，都要隨時關注服務器狀態，好比磁盤空間，網絡抖動；另外，對業務的持續監控也是必不可少的；

三、CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切記不要找錯，若是指定錯了，帶來的後果就是數據不一致；

完整內容點此查看