不同場景下 MySQL 的遷移方案

不同場景下 MySQL 的遷移方案

為什麼要遷移 MySQL 遷移方案概覽 MySQL 遷移實戰 注意事項 技巧 總結   一、為什麼要遷移 MySQL 遷移是 DBA 日常維護中的一個工作。遷移，是把實際存在的物體挪走，保證該物體的完整性以及延續性。   生產環境中，有以下情況需要做遷移：   1、磁盤空間不夠。比如一些老項目，選用的機型並不一定適用於數據庫。隨著時間的推移，硬盤很有可能出現短缺； 2、業務出現瓶頸。比如項目中采用單機承擔所有的讀寫業務，業務壓力增大，不堪重負。如果 IO 壓力在可接受的范圍，會采用讀寫分離方案； 3、機器出現瓶頸。機器出現瓶頸主要在磁盤 IO 能力、內存、CPU，此時除了針對瓶頸做一些優化以外，選擇遷移是不錯的方案； 4、項目改造。某些項目的數據庫存在跨機房的情況，可能會在不同機房中增加節點，或者把機器從一個機房遷移到另一個機房。再比如，不同業務共用同一台服務器，為了緩解服務器壓力以及方便維護，也會做遷移。 一句話，遷移工作是不得已而為之。實施遷移工作，目的是讓業務平穩持續地運行。   二、MySQL 遷移方案概覽 MySQL 遷移就是在保證業務平穩持續地運行的前提下做備份恢復。那問題就在怎麼快速安全地進行備份恢復。   首先，備份。針對每個主節點的從節點或者備節點，都有備份。這個備份可能是全備，可能是增量備份。在線備份的方法，可能使用 mysqldump（MySQL 用於轉存儲數據庫的實用程序。它主要產生一個SQL腳本，其中包含從頭重新創建數據庫所必需的命令），xtrabackup（是一個對 InnoDB 做數據備份的工具，支持在線熱備份，是商業備份工具 InnoDB Hotbackup 的一個很好的替代品），mydumper（是一個針對MySQL和Drizzle的高性能多線程備份和恢復工具）等。   針對小容量（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，架構圖如圖 1。102 從節點的數據容量過大，不能使用 mysqldump 的形式備份。和研發溝通後，形成一致的方案。   下面是 A 項目 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 充當從節點，架構圖如圖二。此次遷移只需要遷移指定庫，這些庫容量不是太大，並且可以保證數據不是實時的。   下圖是 B 項目 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 的從節點，架構圖如圖三。此次遷移只需要遷移指定庫，這些庫容量不是太大，並且可以保證數據不是實時的。我們可以看到，此次遷移和場景二很類似，無非做了兩次遷移。   下圖是 C 項目 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 充當從節點。遷移完成後，以前的主節點和從節點廢棄，架構圖如圖四。此次遷移是全庫遷移，容量大，並且需要保證實時。這次的遷移比較特殊，因為采取的策略是先替換新的從庫，再替換新的主庫。所以做法稍微復雜些。   下面是 D 項目 MySQL 架構圖。     具體的做法是這樣：   1、研發將 102 的讀業務切到主庫；   2、確認 102 MySQL 狀態（主要看 PROCESS LIST，MASTER STATUS），觀察機器流量，確認無誤後，停止 102 從節點的服務；   3、104 新建 MySQL 實例，建成以後，停止 MySQL 服務，並且將整個數據目錄 mv 到其他地方做備份，注意，此處操作的是 104，也就是未來的從庫；   4、將 102 的整個 mysql 數據目錄使用 rsync 拷貝到 104；   5、拷貝的同時，在 101 授權，使 104 有拉取 binlog 的權限（REPLICATION SLAVE, REPLICATION CLIENT）；   6、待拷貝完成，修改 104 配置文件中的 server_id，注意不要和 102 上的一致；   7、在 104 啟動 MySQL 實例，注意配置文件中的數據文件路徑以及數據目錄的權限；   8、進入 104 MySQL 實例，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；   9、Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 101 和 104 的數據一致，但比較耗時，而且對主節點有影響，可以和開發一起進行數據一致性的驗證；   10、除了做數據一致性驗證外，還需要驗證賬號權限，以防業務遷走後訪問出錯；   11、和研發協作，將之前 102 從節點的讀業務切到 104；   12、利用 102 的數據，將 103 變為 101 的從節點，方法同上；   13、接下來到了關鍵的地方了，我們需要把 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 的從節點了。   14、業務遷移之前，斷掉 103 和 101 的同步關系；   15、做完上述步驟，可以和研發協調，把 101 的讀寫業務切回 102，讀業務切到 104。需要注意的是，此時 101 和 103 均可以寫，需要保證 101 在沒有寫入的情況下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 鎖住 101，然後業務切到 103。注意，一定要業務低峰執行，切記；   16、切換完成後，觀察業務狀態；   17、如果業務沒有問題，證明遷移成功。   3.5，場景五：雙主結構跨機房遷移 接下來看看雙主結構跨機房遷移怎麼做。某項目出於容災考慮，使用了跨機房，采用了雙主結構，雙邊均可以寫。因為磁盤空間問題，需要對 A 地的機器進行替換。打算將主節點 1.101 和從節點 1.102 同時遷移至新的機器 1.103 和 1.104，1.103 充當主節點，1.104 充當從節點。B 地的 2.101 和 2.102 保持不變，但遷移完成後，1.103 和 2.101 互為雙主。架構圖如圖五。因為是雙主結構，兩邊同時寫，如果要替換主節點，單方必須有節點停止服務。   下圖是 E 項目 MySQL 遷移架構圖。     具體的做法如下：   1、1.103 和 1.104 新建實例，搭建主從關系，此時的主節點和從節點處於空載；   2、確認 1.102 MySQL 狀態（主要看 PROCESS LIST），注意觀察 MASTER STATUS 不再變化。觀察機器流量，確認無誤後，停止 1.102 從節點的服務；   3、1.103 新建 MySQL 實例，建成以後，停止 MySQL 服務，並且將整個數據目錄 mv 到其他地方做備份；   4、將 1.102 的整個 mysql 數據目錄使用 rsync 拷貝到 1.103；   5、拷貝的同時，在 1.101 授權，使 1.103 有拉取 binlog 的權限（REPLICATION SLAVE, REPLICATION CLIENT）；   6、待拷貝完成，修改 1.103 配置文件中的 server_id，注意不要和 1.102 上的一致；   7、在 1.103 啟動 MySQL 實例，注意配置文件中的數據文件路徑以及數據目錄的權限；   8、進入 1.103 MySQL 實例，使用 SHOW SLAVE STATUS 檢查從庫狀態，可以看到 Seconds_Behind_Master 在遞減；   9、Seconds_Behind_Master 變為 0 後，表示同步完成，此時可以用 pt-table-checksum 檢查 1.101 和 1.103 的數據一致，但比較耗時，而且對主節點有影響，可以和開發一起進行數據一致性的驗證；   10、我們使用相同的辦法，使 1.104 變成 1.103 的從庫；   11、和研發溝通，除了做數據一致性驗證外，還需要驗證賬號權限，以防業務遷走後訪問出錯；   12、此時，我們要做的就是將 1.103 變成 2.101 的從庫，具體的做法可以參考場景四；   13、需要注意的是，1.103 的單雙號配置需要和 1.101 一致；   14、做完上述步驟，可以和研發協調，把 1.101 的讀寫業務切到 1.103，把 1.102 的讀業務切到 1.104。觀察業務狀態；   15、如果業務沒有問題，證明遷移成功。   3.6，場景六：多實例跨機房遷移 接下來我們看看多實例跨機房遷移證明做。每台機器的實例關系，我們可以參考圖六。此次遷移的目的是為了做數據修復。在 2.117 上建立 7938 和 7939 實例，替換之前數據異常的實例。因為業務的原因，某些庫只在 A 地寫，某些庫只在 B 地寫，所以存在同步過濾的情況。   下圖是 F 項目 MySQL 架構圖。     具體的做法如下：   1、1.113 針對 7936 實例使用 innobackupex 做數據備份，注意需要指定數據庫，並且加上 slave-info 參數；   2、備份完成後，將壓縮文件拷貝到 2.117；   3、2.117 創建數據目錄以及配置文件涉及的相關目錄；   4、2.117 使用 innobackupex 恢復日志；   5、2.117 使用 innobackupex 拷貝數據；   6、2.117 修改配置文件，注意如下參數：replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id；   7、2.117 更改數據目錄權限；   8、1.112 授權，使 2.117 有拉取 binlog 的權限（REPLICATION SLAVE, REPLICATION CLIENT）；   9、2.117 CHANGE MASTE TO 1.112，LOG FILE 和 LOG POS 參考 xtrabackup_slave_info；   10、2.117 START SLAVE，查看從庫狀態；   11、2.117 上建立 7939 的方法類似，不過配置文件需要指定 replicate-wild-do-table；   12、和開發一起進行數據一致性的驗證和驗證賬號權限，以防業務遷走後訪問出錯；   13、做完上述步驟，可以和研發協調，把相應業務遷移到 2.117 的 7938 實例和 7939 實例。觀察業務狀態；   14、如果業務沒有問題，證明遷移成功。   四、注意事項 介紹完不同場景的遷移方案，需要注意如下幾點：   1、數據庫遷移，如果涉及事件，記住主節點打開 event_scheduler 參數；   2、不管什麼場景下的遷移，都要隨時關注服務器狀態，比如磁盤空間，網絡抖動；另外，對業務的持續監控也是必不可少的；   3、CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切記不要找錯，如果指定錯了，帶來的後果就是數據不一致；   4、執行腳本不要在 $HOME 目錄，記住在數據目錄；   5、遷移工作可以使用腳本做到自動化，但不要弄巧成拙，任何腳本都要經過測試；   6、每執行一條命令都要三思和後行，每個命令的參數含義都要搞明白；   7、多實例環境下，關閉 MySQL 采用 mysqladmin 的形式，不要把正在使用的實例關閉了；   8、從庫記得把 read_only = 1 加上，這會避免很多問題；   9、每台機器的 server_id 必須保證不一致，否則會出現同步異常的情況；   10、正確配置 replicate-ignore-db 和 replicate-wild-do-table；   11、新建的實例記得把 innodb_file_per_table 設置為 1，上述中的部分場景，因為之前的實例此參數為 0，導致 ibdata1 過大，備份和傳輸都消耗了很多時間；   12、使用 gzip 壓縮數據時，注意壓縮完成後，gzip 會把源文件刪除。   13、所有的操作務必在從節點或者備節點操作，如果在主節點操作，主節點很可能會宕機；   14、xtrabackup 備份不會鎖定 InnoDB 表，但會鎖定 MyISAM 表。所以，操作之前記得檢查下當前數據庫的表是否有使用 MyISAM 存儲引擎的，如果有，要麼單獨處理，要麼更改表的 Engine；   五、技巧 在 MySQL 遷移實戰中，有如下技巧可以使用：   1、任何遷移 LOG FILE 以 relay_master_log_file（正在同步 master 上的 binlog 日志名）為准，LOG POS 以 exec_master_log_pos（正在同步當前 binlog 日志的 POS 點）為准；   2、使用 rsync 拷貝數據，可以結合 expect、nohup 使用，絕對是絕妙組合；   3、在使用 innobackupex 備份數據的同時可以使用 gzip 進行壓縮；   4、在使用 innobackupex 備份數據，可以加上 --slave-info 參數，方便做從庫；   5、在使用 innobackupex 備份數據，可以加上 --throttle 參數，限制 IO，減少對業務的影響。還可以加上 --parallel=n 參數，加快備份，但需要注意的是，使用 tar 流壓縮，--parallel 參數無效。   6、做數據的備份與恢復，可以把待辦事項列個清單，畫個流程，然後把需要執行的命令提前准備好；   7、本地快速拷貝文件夾，有個不錯的方法，使用 rsync，加上如下參數：-avhW --no-compress --progress；   8、 不同分區之間快速拷貝數據，可以使用 dd。或者用一個更靠譜的方法，備份到硬盤，然後放到服務器上。異地還有更絕的，直接快遞硬盤。   六、總結 本文從為什麼要遷移講起，接下來講了遷移方案，然後講解了不同場景下的遷移實戰，最後給出了注意事項以及實戰技巧。歸納起來，也就以下幾點：   第一、遷移的目的是讓業務平穩持續地運行；   第二、遷移的核心是怎麼延續主從同步，我們需要在不同服務器和不同業務之間找到方案；   第三、業務切換需要考慮不同 MySQL 服務器之間的權限問題；需要考慮不同機器讀寫分離的順序以及主從關系；需要考慮跨機房調用對業務的影響。   讀者在實施遷移的過程中，可以參考此文提供的思路。但怎樣保證每個操作正確無誤地運行，還需要三思而後行。   說句題外話，「證明自己有能力最重要的一點就是讓一切都在自己的掌控之中。