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

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

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

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

1. 為了保護(hù)隱私，本文中的服務(wù)器 IP 等信息經(jīng)過處理；
2. 如果服務(wù)器在同一機(jī)房，用服務(wù)器 IP 的 D 段代替服務(wù)器，具體的 IP 請(qǐng)參考架構(gòu)圖；
3. 如果服務(wù)器在不同機(jī)房，用服務(wù)器 IP 的 C 段 和 D 段代替服務(wù)器，具體的 IP 請(qǐng)參考架構(gòu)圖；
4. 每個(gè)場(chǎng)景給出方法，但不會(huì)詳細(xì)地給出每一步執(zhí)行什么命令，因?yàn)橐环矫妫@會(huì)導(dǎo)致文章過長(zhǎng)；另一方面，我認(rèn)為只要知道方法，具體的做法就會(huì)迎面撲來的，只取決于掌握知識(shí)的程度和獲取信息的能力；
5. 實(shí)戰(zhàn)過程中的注意事項(xiàng)請(qǐng)參考第五節(jié)。

4.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)無誤后，停止 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ù)沒有問題，證明遷移成功。

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

我們知道一主一從只遷移從庫(kù)怎么做之后，接下來看看怎樣同時(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ù)沒有問題，證明遷移成功。

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

接下來看看一主一從結(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)景二很類似，無非做了兩次遷移。

圖三 一主一從結(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ù)沒有問題，證明遷移成功。

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

接下來看看一主一從結(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)無誤后，停止 102 從節(jié)點(diǎn)的服務(wù)；
• 104 新建 MySQL 實(shí)例，建成以后，停止 MySQL 服務(wù)，并且將整個(gè)數(shù)據(jù)目錄 mv 到其他地方做備份，注意，此處操作的是 104，也就是未來的從庫(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)，方法同上；
• 接下來到了關(guān)鍵的地方了，我們需要把 104 變成 103 的從庫(kù)；
  • 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 清除從庫(kù)配置信息；
  • 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ù)沒有問題，證明遷移成功。

4.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 檢查從庫(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ù)沒有問題，證明遷移成功。

4.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ù)的原因，某些庫(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ù)沒有問題，證明遷移成功。