不同情況下的MySQL 的遷移方案（推薦）

一、為什么要遷移

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

生產(chǎn)環(huán)境中，有以下情況需要做遷移工作，如下：

• 磁盤空間不夠。比如一些老項(xiàng)目，選用的機(jī)型并不一定適用于數(shù)據(jù)庫(kù)。隨著時(shí)間的推移，硬盤很有可能出現(xiàn)短缺；

• 業(yè)務(wù)出現(xiàn)瓶頸。比如項(xiàng)目中采用單機(jī)承擔(dān)所有的讀寫業(yè)務(wù)，業(yè)務(wù)壓力增大，不堪重負(fù)。如果 IO 壓力在可接受的范圍，會(huì)采用讀寫分離方案；

• 機(jī)器出現(xiàn)瓶頸。機(jī)器出現(xiàn)瓶頸主要在磁盤 IO 能力、內(nèi)存、CPU，此時(shí)除了針對(duì)瓶頸做一些優(yōu)化以外，選擇遷移是不錯(cuò)的方案；

• 項(xiàng)目改造。某些項(xiàng)目的數(shù)據(jù)庫(kù)存在跨機(jī)房的情況，可能會(huì)在不同機(jī)房中增加節(jié)點(diǎn)，或者把機(jī)器從一個(gè)機(jī)房遷移到另一個(gè)機(jī)房。再比如，不同業(yè)務(wù)共用同一臺(tái)服務(wù)器，為了緩解服務(wù)器壓力以及方便維護(hù)，也會(huì)做遷移。

一句話，遷移工作是不得已而為之。實(shí)施遷移工作，目的是讓業(yè)務(wù)平穩(wěn)持續(xù)地運(yùn)行。

二、MySQL 遷移方案概覽

MySQL 遷移無(wú)非是圍繞著數(shù)據(jù)做工作，再繼續(xù)延伸，無(wú)非就是在保證業(yè)務(wù)平穩(wěn)持續(xù)地運(yùn)行的前提下做備份恢復(fù)。那問題就在怎么快速安全地進(jìn)行備份恢復(fù)。

一方面，備份。針對(duì)每個(gè)主節(jié)點(diǎn)的從節(jié)點(diǎn)或者備節(jié)點(diǎn)，都有備份。這個(gè)備份可能是全備，可能是增量備份。在線備份的方法，可能是使用 mysqldump，可能是 xtrabackup，還可能是 mydumper。針對(duì)小容量（10GB 以下）數(shù)據(jù)庫(kù)的備份，我們可以使用 mysqldump。但針對(duì)大容量數(shù)據(jù)庫(kù)（數(shù)百GB 或者 TB 級(jí)別），我們不能使用 mysqldump 備份，一方面，會(huì)產(chǎn)生鎖；另一方面，耗時(shí)太長(zhǎng)。這種情況，可以選擇 xtrabackup 或者直接拷貝數(shù)據(jù)目錄。直接拷貝數(shù)據(jù)目錄方法，不同機(jī)器傳輸可以使用 rsync，耗時(shí)跟網(wǎng)絡(luò)相關(guān)。使用 xtrabackup，耗時(shí)主要在備份和網(wǎng)絡(luò)傳輸。如果有全備或者指定庫(kù)的備份文件，這是獲取備份的最好方法。如果備庫(kù)可以容許停止服務(wù)，直接拷貝數(shù)據(jù)目錄是最快的方法。如果備庫(kù)不允許停止服務(wù)，我們可以使用 xtrabackup（不會(huì)鎖定 InnoDB 表），這是完成備份的最佳折中辦法。

另一方面，恢復(fù)。針對(duì)小容量（10GB 以下）數(shù)據(jù)庫(kù)的備份文件，我們可以直接導(dǎo)入。針對(duì)大容量數(shù)據(jù)庫(kù)（數(shù)百GB 或者 TB 級(jí)別）的恢復(fù)，拿到備份文件到本機(jī)以后，恢復(fù)不算困難。具體的恢復(fù)方法可以參考第四節(jié)。

三、MySQL 遷移實(shí)戰(zhàn)

我們搞明白為什么要做遷移，以及遷移怎么做以后，接下來(lái)看看生產(chǎn)環(huán)境是怎樣操作的。不同的應(yīng)用場(chǎng)景，有不同的解決方案。

閱讀具體的實(shí)戰(zhàn)之前，假設(shè)和讀者有如下約定：

• 為了保護(hù)隱私，本文中的服務(wù)器 IP 等信息經(jīng)過處理；

• 如果服務(wù)器在同一機(jī)房，用服務(wù)器 IP 的 D 段代替服務(wù)器，具體的 IP 請(qǐng)參考架構(gòu)圖；

• 如果服務(wù)器在不同機(jī)房，用服務(wù)器 IP 的 C 段 和 D 段代替服務(wù)器，具體的 IP 請(qǐng)參考架構(gòu)圖；

• 每個(gè)場(chǎng)景給出方法，但不會(huì)詳細(xì)地給出每一步執(zhí)行什么命令，因?yàn)橐环矫�，這會(huì)導(dǎo)致文章過長(zhǎng)；另一方面，我認(rèn)為只要知道方法，具體的做法就會(huì)迎面撲來(lái)的，只取決于掌握知識(shí)的程度和獲取信息的能力；

• 實(shí)戰(zhàn)過程中的注意事項(xiàng)請(qǐng)參考第五節(jié)。

3.1 場(chǎng)景一 一主一從結(jié)構(gòu)遷移從庫(kù)

遵循從易到難的思路，我們從簡(jiǎn)單的結(jié)構(gòu)入手。A 項(xiàng)目，原本是一主一從結(jié)構(gòu)。101 是主節(jié)點(diǎn)，102 是從節(jié)點(diǎn)。因業(yè)務(wù)需要，把 102 從節(jié)點(diǎn)遷移至 103，架構(gòu)圖如圖一。102 從節(jié)點(diǎn)的數(shù)據(jù)容量過大，不能使用 mysqldump 的形式備份。和研發(fā)溝通后，形成一致的方案。

圖一 一主一從結(jié)構(gòu)遷移從庫(kù)架構(gòu)圖

具體做法是這樣：

• 研發(fā)將 102 的讀業(yè)務(wù)切到主庫(kù)；

• 確認(rèn) 102 MySQL 狀態(tài)（主要看 PROCESS LIST），觀察機(jī)器流量，確認(rèn)無(wú)誤后，停止 102 從節(jié)點(diǎn)的服務(wù)；

• 103 新建 MySQL 實(shí)例，建成以后，停止 MySQL 服務(wù)，并且將整個(gè)數(shù)據(jù)目錄 mv 到其他地方做備份；

• 將 102 的整個(gè) mysql 數(shù)據(jù)目錄使用 rsync 拷貝到 103；

• 拷貝的同時(shí)，在 101 授權(quán)，使 103 有拉取 binlog 的權(quán)限（REPLICATION SLAVE, REPLICATION CLIENT）；

• 待拷貝完成，修改 103 配置文件中的 server_id，注意不要和 102 上的一致；

• 在 103 啟動(dòng) MySQL 實(shí)例，注意配置文件中的數(shù)據(jù)文件路徑以及數(shù)據(jù)目錄的權(quán)限；

• 進(jìn)入 103 MySQL 實(shí)例，使用 SHOW SLAVE STATUS 檢查從庫(kù)狀態(tài)，可以看到 Seconds_Behind_Master 在遞減；

• Seconds_Behind_Master 變?yōu)?0 后，表示同步完成，此時(shí)可以用 pt-table-checksum 檢查 101 和 103 的數(shù)據(jù)一致，但比較耗時(shí)，而且對(duì)主節(jié)點(diǎn)有影響，可以和開發(fā)一起進(jìn)行數(shù)據(jù)一致性的驗(yàn)證；

• 和研發(fā)溝通，除了做數(shù)據(jù)一致性驗(yàn)證外，還需要驗(yàn)證賬號(hào)權(quán)限，以防業(yè)務(wù)遷回后訪問出錯(cuò)；

• 做完上述步驟，可以和研發(fā)協(xié)調(diào)，把 101 的部分讀業(yè)務(wù)切到 103，觀察業(yè)務(wù)狀態(tài)；

• 如果業(yè)務(wù)沒有問題，證明遷移成功。

3.2 場(chǎng)景二 一主一從結(jié)構(gòu)遷移指定庫(kù)

我們知道一主一從只遷移從庫(kù)怎么做之后，接下來(lái)看看怎樣同時(shí)遷移主從節(jié)點(diǎn)。因不同業(yè)務(wù)同時(shí)訪問同一服務(wù)器，導(dǎo)致單個(gè)庫(kù)壓力過大，還不便管理。于是，打算將主節(jié)點(diǎn) 101 和從節(jié)點(diǎn) 102 同時(shí)遷移至新的機(jī)器 103 和 104，103 充當(dāng)主節(jié)點(diǎn)，104 充當(dāng)從節(jié)點(diǎn)，架構(gòu)圖如圖二。此次遷移只需要遷移指定庫(kù)，這些庫(kù)容量不是太大，并且可以保證數(shù)據(jù)不是實(shí)時(shí)的。

圖二 一主一從結(jié)構(gòu)遷移指定庫(kù)架構(gòu)圖

具體的做法如下：

• 103 和 104 新建實(shí)例，搭建主從關(guān)系，此時(shí)的主節(jié)點(diǎn)和從節(jié)點(diǎn)處于空載；

• 102 導(dǎo)出數(shù)據(jù)，正確的做法是配置定時(shí)任務(wù)，在業(yè)務(wù)低峰做導(dǎo)出操作，此處選擇的是 mysqldump；

• 102 收集指定庫(kù)需要的賬號(hào)以及權(quán)限；

• 102 導(dǎo)出數(shù)據(jù)完畢，使用 rsync 傳輸?shù)?103，必要時(shí)做壓縮操作；

• 103 導(dǎo)入數(shù)據(jù)，此時(shí)數(shù)據(jù)會(huì)自動(dòng)同步到 104，監(jiān)控服務(wù)器狀態(tài)以及 MySQL 狀態(tài)；

• 103 導(dǎo)入完成，104 同步完成，103 根據(jù) 102 收集的賬號(hào)授權(quán)，完成后，通知研發(fā)檢查數(shù)據(jù)以及賬戶權(quán)限；

• 上述完成后，可研發(fā)協(xié)作，將 101 和 102 的業(yè)務(wù)遷移到 103 和 104，觀察業(yè)務(wù)狀態(tài)；

• 如果業(yè)務(wù)沒有問題，證明遷移成功。

3.3 場(chǎng)景三 一主一從結(jié)構(gòu)雙邊遷移指定庫(kù)

接下來(lái)看看一主一從結(jié)構(gòu)雙邊遷移指定庫(kù)怎么做。同樣是因?yàn)闃I(yè)務(wù)共用，導(dǎo)致服務(wù)器壓力大，管理混亂。于是，打算將主節(jié)點(diǎn) 101 和從節(jié)點(diǎn) 102 同時(shí)遷移至新的機(jī)器 103、104、105、106，103 充當(dāng) 104 的主節(jié)點(diǎn)，104 充當(dāng) 103 的從節(jié)點(diǎn)，105 充當(dāng) 106 的主節(jié)點(diǎn)，106 充當(dāng) 105 的從節(jié)點(diǎn)，架構(gòu)圖如圖三。此次遷移只需要遷移指定庫(kù)，這些庫(kù)容量不是太大，并且可以保證數(shù)據(jù)不是實(shí)時(shí)的。我們可以看到，此次遷移和場(chǎng)景二很類似，無(wú)非做了兩次遷移。

圖三 一主一從結(jié)構(gòu)雙邊遷移指定庫(kù)架構(gòu)圖

具體的做法如下：

• 103 和 104 新建實(shí)例，搭建主從關(guān)系，此時(shí)的主節(jié)點(diǎn)和從節(jié)點(diǎn)處于空載；

• 102 導(dǎo)出 103 需要的指定庫(kù)數(shù)據(jù)，正確的做法是配置定時(shí)任務(wù)，在業(yè)務(wù)低峰做導(dǎo)出操作，此處選擇的是 mysqldump；

• 102 收集 103 需要的指定庫(kù)需要的賬號(hào)以及權(quán)限；

• 102 導(dǎo)出103 需要的指定庫(kù)數(shù)據(jù)完畢，使用 rsync 傳輸?shù)?103，必要時(shí)做壓縮操作；

• 103 導(dǎo)入數(shù)據(jù)，此時(shí)數(shù)據(jù)會(huì)自動(dòng)同步到 104，監(jiān)控服務(wù)器狀態(tài)以及 MySQL 狀態(tài)；

• 103 導(dǎo)入完成，104 同步完成，103 根據(jù) 102 收集的賬號(hào)授權(quán)，完成后，通知研發(fā)檢查數(shù)據(jù)以及賬戶權(quán)限；

• 上述完成后，和研發(fā)協(xié)作，將 101 和 102 的業(yè)務(wù)遷移到 103 和 104，觀察業(yè)務(wù)狀態(tài)；

• 105 和 106 新建實(shí)例，搭建主從關(guān)系，此時(shí)的主節(jié)點(diǎn)和從節(jié)點(diǎn)處于空載；

• 102 導(dǎo)出 105 需要的指定庫(kù)數(shù)據(jù)，正確的做法是配置定時(shí)任務(wù)，在業(yè)務(wù)低峰做導(dǎo)出操作，此處選擇的是 mysqldump；

• 102 收集 105 需要的指定庫(kù)需要的賬號(hào)以及權(quán)限；

• 102 導(dǎo)出 105 需要的指定庫(kù)數(shù)據(jù)完畢，使用 rsync 傳輸?shù)?105，必要時(shí)做壓縮操作；

• 105 導(dǎo)入數(shù)據(jù)，此時(shí)數(shù)據(jù)會(huì)自動(dòng)同步到 106，監(jiān)控服務(wù)器狀態(tài)以及 MySQL 狀態(tài)；

• 105 導(dǎo)入完成，106 同步完成，105 根據(jù) 102 收集的賬號(hào)授權(quán)，完成后，通知研發(fā)檢查數(shù)據(jù)以及賬戶權(quán)限；

• 上述完成后，和研發(fā)協(xié)作，將 101 和 102 的業(yè)務(wù)遷移到 105 和 106，觀察業(yè)務(wù)狀態(tài)；

• 如果所有業(yè)務(wù)沒有問題，證明遷移成功。

3.4 場(chǎng)景四 一主一從結(jié)構(gòu)完整遷移主從

接下來(lái)看看一主一從結(jié)構(gòu)完整遷移主從怎么做。和場(chǎng)景二類似，不過此處是遷移所有庫(kù)。因 101 主節(jié)點(diǎn) IO 出現(xiàn)瓶頸，打算將主節(jié)點(diǎn) 101 和從節(jié)點(diǎn) 102 同時(shí)遷移至新的機(jī)器 103 和 104，103 充當(dāng)主節(jié)點(diǎn)，104 充當(dāng)從節(jié)點(diǎn)。遷移完成后，以前的主節(jié)點(diǎn)和從節(jié)點(diǎn)廢棄，架構(gòu)圖如圖四。此次遷移是全庫(kù)遷移，容量大，并且需要保證實(shí)時(shí)。這次的遷移比較特殊，因?yàn)椴扇〉牟呗允窍忍鎿Q新的從庫(kù)，再替換新的主庫(kù)。所以做法稍微復(fù)雜些。

圖四 一主一從結(jié)構(gòu)完整遷移主從架構(gòu)圖

具體的做法是這樣：

• 研發(fā)將 102 的讀業(yè)務(wù)切到主庫(kù)；

• 確認(rèn) 102 MySQL 狀態(tài)（主要看 PROCESS LIST，MASTER STATUS），觀察機(jī)器流量，確認(rèn)無(wú)誤后，停止 102 從節(jié)點(diǎn)的服務(wù)；

• 104 新建 MySQL 實(shí)例，建成以后，停止 MySQL 服務(wù)，并且將整個(gè)數(shù)據(jù)目錄 mv 到其他地方做備份，注意，此處操作的是 104，也就是未來(lái)的從庫(kù)；

• 將 102 的整個(gè) mysql 數(shù)據(jù)目錄使用 rsync 拷貝到 104；

• 拷貝的同時(shí)，在 101 授權(quán)，使 104 有拉取 binlog 的權(quán)限（REPLICATION SLAVE, REPLICATION CLIENT）；

• 待拷貝完成，修改 104 配置文件中的 server_id，注意不要和 102 上的一致；

• 在 104 啟動(dòng) MySQL 實(shí)例，注意配置文件中的數(shù)據(jù)文件路徑以及數(shù)據(jù)目錄的權(quán)限；

• 進(jìn)入 104 MySQL 實(shí)例，使用 SHOW SLAVE STATUS 檢查從庫(kù)狀態(tài)，可以看到 Seconds_Behind_Master 在遞減；

• Seconds_Behind_Master 變?yōu)?0 后，表示同步完成，此時(shí)可以用 pt-table-checksum 檢查 101 和 104 的數(shù)據(jù)一致，但比較耗時(shí)，而且對(duì)主節(jié)點(diǎn)有影響，可以和開發(fā)一起進(jìn)行數(shù)據(jù)一致性的驗(yàn)證；

• 除了做數(shù)據(jù)一致性驗(yàn)證外，還需要驗(yàn)證賬號(hào)權(quán)限，以防業(yè)務(wù)遷走后訪問出錯(cuò)；

• 和研發(fā)協(xié)作，將之前 102 從節(jié)點(diǎn)的讀業(yè)務(wù)切到 104；

• 利用 102 的數(shù)據(jù)，將 103 變?yōu)?101 的從節(jié)點(diǎn)，方法同上；

• 接下來(lái)到了關(guān)鍵的地方了，我們需要把 104 變成 103 的從庫(kù)；

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 清除從庫(kù)配置信息；

7. 103 SHOW MASTER STATUS，記住 MASTER_LOG_FILE 和 MASTER_LOG_POS；

8. 103 授權(quán)給 104 訪問 binlog 的權(quán)限；

9. 104 CHANGE MASTER TO 103；

10. 104 重啟 MySQL，因?yàn)?RESET SLAVE ALL 后，查看 SLAVE STATUS，Master_Server_Id 仍然為 101，而不是 103；

11. 104 MySQL 重啟后，SLAVE 回自動(dòng)重啟，此時(shí)查看 IO_THREAD 和 SQL_THREAD 是否為 YES；

12. 103 START SLAVE；

13. 此時(shí)查看 103 和 104 的狀態(tài)，可以發(fā)現(xiàn)，以前 104 是 101 的從節(jié)點(diǎn)，如今變成 103 的從節(jié)點(diǎn)了。

• 業(yè)務(wù)遷移之前，斷掉 103 和 101 的同步關(guān)系；

• 做完上述步驟，可以和研發(fā)協(xié)調(diào)，把 101 的讀寫業(yè)務(wù)切回 102，讀業(yè)務(wù)切到 104。需要注意的是，此時(shí) 101 和 103 均可以寫，需要保證 101 在沒有寫入的情況下切到 103，可以使用 FLUSH TABLES WITH READ LOCK 鎖住 101，然后業(yè)務(wù)切到 103。注意，一定要業(yè)務(wù)低峰執(zhí)行，切記；

• 切換完成后，觀察業(yè)務(wù)狀態(tài)；

• 如果業(yè)務(wù)沒有問題，證明遷移成功。

3.5 場(chǎng)景五 雙主結(jié)構(gòu)跨機(jī)房遷移

接下來(lái)看看雙主結(jié)構(gòu)跨機(jī)房遷移怎么做。某項(xiàng)目出于容災(zāi)考慮，使用了跨機(jī)房，采用了雙主結(jié)構(gòu)，雙邊均可以寫。因?yàn)榇疟P空間問題，需要對(duì) A 地的機(jī)器進(jìn)行替換。打算將主節(jié)點(diǎn) 1.101 和從節(jié)點(diǎn) 1.102 同時(shí)遷移至新的機(jī)器 1.103 和 1.104，1.103 充當(dāng)主節(jié)點(diǎn)，1.104 充當(dāng)從節(jié)點(diǎn)。B 地的 2.101 和 2.102 保持不變，但遷移完成后，1.103 和 2.101 互為雙主。架構(gòu)圖如圖五。因?yàn)槭请p主結(jié)構(gòu)，兩邊同時(shí)寫，如果要替換主節(jié)點(diǎn)，單方必須有節(jié)點(diǎn)停止服務(wù)。

圖五 雙主結(jié)構(gòu)跨機(jī)房遷移架構(gòu)圖

具體的做法如下：

• 1.103 和 1.104 新建實(shí)例，搭建主從關(guān)系，此時(shí)的主節(jié)點(diǎn)和從節(jié)點(diǎn)處于空載；

• 確認(rèn) 1.102 MySQL 狀態(tài)（主要看 PROCESS LIST），注意觀察 MASTER STATUS 不再變化。觀察機(jī)器流量，確認(rèn)無(wú)誤后，停止 1.102 從節(jié)點(diǎn)的服務(wù)；

• 1.103 新建 MySQL 實(shí)例，建成以后，停止 MySQL 服務(wù)，并且將整個(gè)數(shù)據(jù)目錄 mv 到其他地方做備份；

• 將 1.102 的整個(gè) mysql 數(shù)據(jù)目錄使用 rsync 拷貝到 1.103；

• 拷貝的同時(shí)，在 1.101 授權(quán)，使 1.103 有拉取 binlog 的權(quán)限（REPLICATION SLAVE, REPLICATION CLIENT）；

• 待拷貝完成，修改 1.103 配置文件中的 server_id，注意不要和 1.102 上的一致；

• 在 1.103 啟動(dòng) MySQL 實(shí)例，注意配置文件中的數(shù)據(jù)文件路徑以及數(shù)據(jù)目錄的權(quán)限；

• 進(jìn)入 1.103 MySQL 實(shí)例，使用 SHOW SLAVE STATUS 檢查從庫(kù)狀態(tài)，可以看到 Seconds_Behind_Master 在遞減；

• Seconds_Behind_Master 變?yōu)?0 后，表示同步完成，此時(shí)可以用 pt-table-checksum 檢查 1.101 和 1.103 的數(shù)據(jù)一致，但比較耗時(shí)，而且對(duì)主節(jié)點(diǎn)有影響，可以和開發(fā)一起進(jìn)行數(shù)據(jù)一致性的驗(yàn)證；

• 我們使用相同的辦法，使 1.104 變成 1.103 的從庫(kù)；

• 和研發(fā)溝通，除了做數(shù)據(jù)一致性驗(yàn)證外，還需要驗(yàn)證賬號(hào)權(quán)限，以防業(yè)務(wù)遷走后訪問出錯(cuò)；

• 此時(shí)，我們要做的就是將 1.103 變成 2.101 的從庫(kù)，具體的做法可以參考場(chǎng)景四；

• 需要注意的是，1.103 的單雙號(hào)配置需要和 1.101 一致；

• 做完上述步驟，可以和研發(fā)協(xié)調(diào)，把 1.101 的讀寫業(yè)務(wù)切到 1.103，把 1.102 的讀業(yè)務(wù)切到 1.104。觀察業(yè)務(wù)狀態(tài)；

• 如果業(yè)務(wù)沒有問題，證明遷移成功。

3.6 場(chǎng)景六 多實(shí)例跨機(jī)房遷移

接下來(lái)我們看看多實(shí)例跨機(jī)房遷移證明做。每臺(tái)機(jī)器的實(shí)例關(guān)系，我們可以參考圖六。此次遷移的目的是為了做數(shù)據(jù)修復(fù)。在 2.117 上建立 7938 和 7939 實(shí)例，替換之前數(shù)據(jù)異常的實(shí)例。因?yàn)闃I(yè)務(wù)的原因，某些庫(kù)只在 A 地寫，某些庫(kù)只在 B 地寫，所以存在同步過濾的情況。

圖六 多實(shí)例跨機(jī)房遷移架構(gòu)圖

具體的做法如下：

• 1.113 針對(duì) 7936 實(shí)例使用 innobackupex 做數(shù)據(jù)備份，注意需要指定數(shù)據(jù)庫(kù)，并且加上 slave-info 參數(shù)；

• 備份完成后，將壓縮文件拷貝到 2.117；

• 2.117 創(chuàng)建數(shù)據(jù)目錄以及配置文件涉及的相關(guān)目錄；

• 2.117 使用 innobackupex 恢復(fù)日志；

• 2.117 使用 innobackupex 拷貝數(shù)據(jù)；

• 2.117 修改配置文件，注意如下參數(shù)：replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id；

• 2.117 更改數(shù)據(jù)目錄權(quán)限；

• 1.112 授權(quán)，使 2.117 有拉取 binlog 的權(quán)限（REPLICATION SLAVE, REPLICATION CLIENT）；

• 2.117 CHANGE MASTE TO 1.112，LOG FILE 和 LOG POS 參考 xtrabackup_slave_info；

• 2.117 START SLAVE，查看從庫(kù)狀態(tài)；

• 2.117 上建立 7939 的方法類似，不過配置文件需要指定 replicate-wild-do-table；

• 和開發(fā)一起進(jìn)行數(shù)據(jù)一致性的驗(yàn)證和驗(yàn)證賬號(hào)權(quán)限，以防業(yè)務(wù)遷走后訪問出錯(cuò)；

• 做完上述步驟，可以和研發(fā)協(xié)調(diào)，把相應(yīng)業(yè)務(wù)遷移到 2.117 的 7938 實(shí)例和 7939 實(shí)例。觀察業(yè)務(wù)狀態(tài)；

• 如果業(yè)務(wù)沒有問題，證明遷移成功。

四 注意事項(xiàng)

介紹完不同場(chǎng)景的遷移方案，需要注意如下幾點(diǎn)：

• 數(shù)據(jù)庫(kù)遷移，如果涉及事件，記住主節(jié)點(diǎn)打開 event_scheduler 參數(shù)；

• 不管什么場(chǎng)景下的遷移，都要隨時(shí)關(guān)注服務(wù)器狀態(tài)，比如磁盤空間，網(wǎng)絡(luò)抖動(dòng)；另外，對(duì)業(yè)務(wù)的持續(xù)監(jiān)控也是必不可少的；

• CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切記不要找錯(cuò)，如果指定錯(cuò)了，帶來(lái)的后果就是數(shù)據(jù)不一致或者搭建主從關(guān)系失敗；

• 執(zhí)行腳本不要在 $HOME 目錄，記住在數(shù)據(jù)目錄；

• 遷移工作可以使用腳本做到自動(dòng)化，但不要弄巧成拙，任何腳本都要經(jīng)過測(cè)試；

• 每執(zhí)行一條命令都要三思和后行，每個(gè)命令的參數(shù)含義都要搞明白；

• 多實(shí)例環(huán)境下，關(guān)閉 MySQL 采用 mysqladmin 的形式，不要把正在使用的實(shí)例關(guān)閉了；

• 從庫(kù)記得把 read_only = 1 加上，這會(huì)避免很多問題；

• 每臺(tái)機(jī)器的 server_id 必須保證不一致，否則會(huì)出現(xiàn)同步異常的情況；

• 正確配置 replicate-ignore-db 和 replicate-wild-do-table；

• 新建的實(shí)例記得把 innodb_file_per_table 設(shè)置為 1，上述中的部分場(chǎng)景，因?yàn)橹�前的�?shí)例此參數(shù)為 0，導(dǎo)致 ibdata1 過大，備份和傳輸都消耗了很多時(shí)間；

• 使用 gzip 壓縮數(shù)據(jù)時(shí)，注意壓縮完成后，gzip 會(huì)把源文件刪除；

• 所有的操作務(wù)必在從節(jié)點(diǎn)或者備節(jié)點(diǎn)操作，如果在主節(jié)點(diǎn)操作，主節(jié)點(diǎn)很可能會(huì)宕機(jī)；

• xtrabackup 備份不會(huì)鎖定 InnoDB 表，但會(huì)鎖定 MyISAM 表。所以，操作之前記得檢查下當(dāng)前數(shù)據(jù)庫(kù)的表是否有使用 MyISAM 存儲(chǔ)引擎的，如果有，要么單獨(dú)處理，要么更改表的 Engine。

五 技巧

在 MySQL 遷移實(shí)戰(zhàn)中，有如下技巧可以使用：

• 任何遷移 LOG FILE 以 relay_master_log_file（正在同步 master 上的 binlog 日志名）為準(zhǔn)，LOG POS 以 exec_master_log_pos（正在同步當(dāng)前 binlog 日志的 POS 點(diǎn)）為準(zhǔn)；

• 使用 rsync 拷貝數(shù)據(jù)，可以結(jié)合 expect、nohup 使用，絕對(duì)是絕妙組合；

• 在使用 innobackupex 備份數(shù)據(jù)的同時(shí)可以使用 gzip 進(jìn)行壓縮；

• 在使用 innobackupex 備份數(shù)據(jù)，可以加上 –slave-info 參數(shù)，方便做從庫(kù)；

• 在使用 innobackupex 備份數(shù)據(jù)，可以加上 –throttle 參數(shù)，限制 IO，減少對(duì)業(yè)務(wù)的影響。還可以加上 –parallel=n 參數(shù)，加快備份，但需要注意的是，使用 tar 流壓縮，–parallel 參數(shù)無(wú)效；

• 做數(shù)據(jù)的備份與恢復(fù)，可以把待辦事項(xiàng)列個(gè)清單，畫個(gè)流程，然后把需要執(zhí)行的命令提前準(zhǔn)備好；

• 本地快速拷貝文件夾，有個(gè)不錯(cuò)的方法，使用 rsync，加上如下參數(shù)：-avhW –no-compress –progress；

• 不同分區(qū)之間快速拷貝數(shù)據(jù)，可以使用 dd。或者用一個(gè)更靠譜的方法，備份到硬盤，然后放到服務(wù)器上。異地還有更絕的，直接快遞硬盤。

六 總結(jié)

本文從為什么要遷移講起，接下來(lái)講了遷移方案，然后講解了不同場(chǎng)景下的遷移實(shí)戰(zhàn)，最后給出了注意事項(xiàng)以及實(shí)戰(zhàn)技巧。歸納起來(lái)，也就以下幾點(diǎn)：

第一，遷移的目的是讓業(yè)務(wù)平穩(wěn)持續(xù)地運(yùn)行；
第二，遷移的核心是怎么延續(xù)主從同步，我們需要在不同服務(wù)器和不同業(yè)務(wù)之間找到方案；
第三，業(yè)務(wù)切換需要考慮不同 MySQL 服務(wù)器之間的權(quán)限問題；需要考慮不同機(jī)器讀寫分離的順序以及主從關(guān)系；需要考慮跨機(jī)房調(diào)用對(duì)業(yè)務(wù)的影響。

讀者在實(shí)施遷移的過程中，可以參考此文提供的思路。但怎樣保證每個(gè)操作正確無(wú)誤地運(yùn)行，還需要三思而后行。

說句題外話，「證明自己有能力最重要的一點(diǎn)就是讓一切都在自己的掌控之中�！�

以上就是不同情況下的MySQL 的遷移方案（推薦）的詳細(xì)內(nèi)容，更多請(qǐng)關(guān)注php中文網(wǎng)其它相關(guān)文章！