# 四 MySQL 遷移實戰 * * * * * [TOC=2,3] 我們搞明白為什么要做遷移，以及遷移怎么做以后，接下來看看生產環境是怎樣操作的。不同的應用場景，有不同的解決方案。 閱讀具體的實戰之前，假設和讀者有如下約定： 1. 為了保護隱私，本文中的服務器 IP 等信息經過處理； 2. 如果服務器在同一機房，用服務器 IP 的 D 段代替服務器，具體的 IP 請參考架構圖； 3. 如果服務器在不同機房，用服務器 IP 的 C 段 和 D 段代替服務器，具體的 IP 請參考架構圖； 4. 每個場景給出方法，但不會詳細地給出每一步執行什么命令，因為一方面，這會導致文章過長；另一方面，我認為只要知道方法，具體的做法就會迎面撲來的，只取決于掌握知識的程度和獲取信息的能力； 5. 實戰過程中的注意事項請參考第五節。 ### 4.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，觀察業務狀態； * 如果業務沒有問題，證明遷移成功。 ### 4.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，觀察業務狀態； * 如果業務沒有問題，證明遷移成功。 ### 4.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，觀察業務狀態； * 如果所有業務沒有問題，證明遷移成功。 ### 4.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 的從庫； * 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 的從節點了。 * 業務遷移之前，斷掉 103 和 101 的同步關系； * 做完上述步驟，可以和研發協調，把 101 的讀寫業務切回 102，讀業務切到 104。需要注意的是，此時 101 和 103 均可以寫，需要保證 101 在沒有寫入的情況下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 鎖住 101，然后業務切到 103。注意，一定要業務低峰執行，切記； * 切換完成后，觀察業務狀態； * 如果業務沒有問題，證明遷移成功。 ### 4.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。觀察業務狀態； * 如果業務沒有問題，證明遷移成功。 ### 4.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 實例。觀察業務狀態； * 如果業務沒有問題，證明遷移成功。