一、為什么要遷移

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

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

磁盤空間不夠。比如一些老項(xiàng)目，選用的機(jī)型并不一定適用于數(shù)據(jù)庫。隨著時(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ù)庫存在跨機(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 遷移無非是圍繞著數(shù)據(jù)做工作，再繼續(xù)延伸，無非就是在保證業(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ù)庫的備份，我們可以使用 mysqldump。但針對(duì)大容量數(shù)據(jù)庫（數(shù)百GB 或者 TB 級(jí)別），我們不能使用 mysqldump 備份，一方面，會(huì)產(chǎn)生鎖；另一方面，耗時(shí)太長。這種情況，可以選擇 xtrabackup 或者直接拷貝數(shù)據(jù)目錄。直接拷貝數(shù)據(jù)目錄方法，不同機(jī)器傳輸可以使用 rsync，耗時(shí)跟網(wǎng)絡(luò)相關(guān)。使用 xtrabackup，耗時(shí)主要在備份和網(wǎng)絡(luò)傳輸。如果有全備或者指定庫的備份文件，這是獲取備份的最好方法。如果備庫可以容許停止服務(wù)，直接拷貝數(shù)據(jù)目錄是最快的方法。如果備庫不允許停止服務(wù)，我們可以使用 xtrabackup（不會(huì)鎖定 InnoDB 表），這是完成備份的最佳折中辦法。

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

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

我們搞明白為什么要做遷移，以及遷移怎么做以后，接下來看看生產(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)致文章過長；另一方面，我認(rèn)為只要知道方法，具體的做法就會(huì)迎面撲來的，只取決于掌握知識(shí)的程度和獲取信息的能力；實(shí)戰(zhàn)過程中的注意事項(xiàng)請(qǐng)參考第五節(jié)。

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

遵循從易到難的思路，我們從簡單的結(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)遷移從庫架構(gòu)圖

具體做法是這樣：

研發(fā)將 102 的讀業(yè)務(wù)切到主庫；確認(rèn) 102 MySQL 狀態(tài)（主要看 PROCESS LIST），觀察機(jī)器流量，確認(rèn)無誤后，停止 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 檢查從庫狀態(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)遷移指定庫

我們知道一主一從只遷移從庫怎么做之后，接下來看看怎樣同時(shí)遷移主從節(jié)點(diǎn)。因不同業(yè)務(wù)同時(shí)訪問同一服務(wù)器，導(dǎo)致單個(gè)庫壓力過大，還不便管理。于是，打算將主節(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)圖如圖二。此次遷移只需要遷移指定庫，這些庫容量不是太大，并且可以保證數(shù)據(jù)不是實(shí)時(shí)的。

圖二 一主一從結(jié)構(gòu)遷移指定庫架構(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 收集指定庫需要的賬號(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)雙邊遷移指定庫

接下來看看一主一從結(jié)構(gòu)雙邊遷移指定庫怎么做。同樣是因?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)圖如圖三。此次遷移只需要遷移指定庫，這些庫容量不是太大，并且可以保證數(shù)據(jù)不是實(shí)時(shí)的。我們可以看到，此次遷移和場(chǎng)景二很類似，無非做了兩次遷移。

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

具體的做法如下：

103 和 104 新建實(shí)例，搭建主從關(guān)系，此時(shí)的主節(jié)點(diǎn)和從節(jié)點(diǎn)處于空載；102 導(dǎo)出 103 需要的指定庫數(shù)據(jù)，正確的做法是配置定時(shí)任務(wù)，在業(yè)務(wù)低峰做導(dǎo)出操作，此處選擇的是 mysqldump；102 收集 103 需要的指定庫需要的賬號(hào)以及權(quán)限；102 導(dǎo)出103 需要的指定庫數(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 需要的指定庫數(shù)據(jù)，正確的做法是配置定時(shí)任務(wù)，在業(yè)務(wù)低峰做導(dǎo)出操作，此處選擇的是 mysqldump；102 收集 105 需要的指定庫需要的賬號(hào)以及權(quán)限；102 導(dǎo)出 105 需要的指定庫數(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)完整遷移主從

接下來看看一主一從結(jié)構(gòu)完整遷移主從怎么做。和場(chǎng)景二類似，不過此處是遷移所有庫。因 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)圖如圖四。此次遷移是全庫遷移，容量大，并且需要保證實(shí)時(shí)。這次的遷移比較特殊，因?yàn)椴扇〉牟呗允窍忍鎿Q新的從庫，再替換新的主庫。所以做法稍微復(fù)雜些。

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

具體的做法是這樣：

研發(fā)將 102 的讀業(yè)務(wù)切到主庫；確認(rèn) 102 MySQL 狀態(tài)（主要看 PROCESS LIST，MASTER STATUS），觀察機(jī)器流量，確認(rèn)無誤后，停止 102 從節(jié)點(diǎn)的服務(wù)；104 新建 MySQL 實(shí)例，建成以后，停止 MySQL 服務(wù)，并且將整個(gè)數(shù)據(jù)目錄 mv 到其他地方做備份，注意，此處操作的是 104，也就是未來的從庫；將 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 檢查從庫狀態(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)，方法同上；接下來到了關(guān)鍵的地方了，我們需要把 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 授權(quán)給 104 訪問 binlog 的權(quán)限；104 CHANGE MASTER TO 103；104 重啟 MySQL，因?yàn)?RESET SLAVE ALL 后，查看 SLAVE STATUS，Master_Server_Id 仍然為 101，而不是 103；104 MySQL 重啟后，SLAVE 回自動(dòng)重啟，此時(shí)查看 IO_THREAD 和 SQL_THREAD 是否為 YES；103 START SLAVE；此時(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ī)房遷移

接下來看看雙主結(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)無誤后，停止 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 檢查從庫狀態(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 的從庫；和研發(fā)溝通，除了做數(shù)據(jù)一致性驗(yàn)證外，還需要驗(yàn)證賬號(hào)權(quán)限，以防業(yè)務(wù)遷走后訪問出錯(cuò)；此時(shí)，我們要做的就是將 1.103 變成 2.101 的從庫，具體的做法可以參考場(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ī)房遷移

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

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

具體的做法如下：

1.113 針對(duì) 7936 實(shí)例使用 innobackupex 做數(shù)據(jù)備份，注意需要指定數(shù)據(jù)庫，并且加上 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，查看從庫狀態(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ù)庫遷移，如果涉及事件，記住主節(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ò)了，帶來的后果就是數(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)閉了；從庫記得把 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ù)庫的表是否有使用 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ù)，方便做從庫；在使用 innobackupex 備份數(shù)據(jù)，可以加上 –throttle 參數(shù)，限制 IO，減少對(duì)業(yè)務(wù)的影響。還可以加上 –parallel=n 參數(shù)，加快備份，但需要注意的是，使用 tar 流壓縮，–parallel 參數(shù)無效；做數(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é)

本文從為什么要遷移講起，接下來講了遷移方案，然后講解了不同場(chǎng)景下的遷移實(shí)戰(zhàn)，最后給出了注意事項(xiàng)以及實(shí)戰(zhàn)技巧。歸納起來，也就以下幾點(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è)操作正確無誤地運(yùn)行，還需要三思而后行。

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