MySQL 資料庫遷移實戰：六大核心場景完整解析與操作指南

核心原則只有一條：讓業務平穩、持續地運行。 所有遷移方案的設計，皆圍繞「如何快速、安全地完成備份與恢復」展開。

MySQL 遷移工具箱：備份與恢復工具選型

遷移的本質是「備份 + 傳輸 + 恢復 + 同步追趕」。工具選型取決於數據量級：

決策建議： 10GB 內用 mysqldump；TB 級首選 xtrabackup 或停機 rsync；跨機房低帶寬場景建議壓縮後傳輸。

六大經典遷移場景實戰演練

以下場景假設：IP 末尾數字代表節點（如 101, 102），同機房用 D 段區分，跨機房用 C+D 段。所有操作均在從庫/備庫執行，嚴禁在主庫直接操作。

場景一：一主一從架構 —— 遷移從庫 (數據量大，需物理拷貝)

架構： 101 (主) -> 102 (舊從) 遷移至 103 (新從)

1. 業務切流： 研發將 102 的讀流量切回主庫 101。
2. 凍結舊從： 確認 102 無延遲、無活躍線程後，停止 MySQL 服務。
3. 準備新從： 103 建立實例 -> 停止服務 -> 備份空數據目錄 (mv 走)。
4. 物理拷貝： 使用 rsync -avhW --no-compress --progress 將 102 全量數據目錄拷貝至 103。
5. 同步授權： 拷貝期間，在 101 授權 103 具備 REPLICATION SLAVE, REPLICATION CLIENT 權限。
6. 配置調整： 修改 103 server_id (唯一)、數據目錄權限、配置文件路徑。
7. 啟動同步： 啟動 103 MySQL，觀察 SHOW SLAVE STATUS 中 Seconds_Behind_Master 遞減至 0。
8. 驗證上線： pt-table-checksum 校驗一致性 (或業務抽樣驗證) + 權限校驗 -> 研發切讀流量至 103 -> 觀察無誤遷移完成。

關鍵點： 大數據量物理拷貝不鎖主庫，業務影響僅在「切讀流量」瞬間，風險最低。

場景二：一主一從架構 —— 遷移指定庫 (數據量小，邏輯備份)

架構： 101/102 遷移指定庫至 103 (新主) / 104 (新從)，原主從最終廢棄。

1. 搭建新集群： 103/104 建立主從，空載運行。
2. 低峰導出： 102 使用 mysqldump --single-transaction --master-data=2 導出指定庫 (定時任務，業務低峰執行)。
3. 收集權限： 導出 102 上指定庫的用戶權限 (SHOW GRANTS)。
4. 傳輸導入： 壓縮傳輸至 103 導入，數據自動同步至 104。
5. 授權同步： 103 按收集權限建立用戶。
6. 雙寫驗證/切換： 研發驗證數據權限 -> 將 101/102 業務切至 103/104 -> 觀察穩定後下線舊集群。

場景三：一主一從架構 —— 雙邊遷移指定庫 (拆分業務)

架構： 101/102 拆分遷移至 103/104 (業務A) 與 105/106 (業務B)。

本質是場景二的兩次重複執行：先遷移業務A庫至 103/104，驗證切換；再遷移業務B庫至 105/106。核心難點在於權限隔離與業務切換順序的管控，建議制定詳細的變更單，分時段、分批次執行。

場景四：一主一從架構 —— 全量遷移主從 (TB 級，強一致性，先換從後換主)

架構： 101/102 全量遷移至 103/104，原集群下線。核心策略：先建立新從 104，再將新主 103 掛在舊主 101 下，最後反向切換主從關係。

1. 建立新從 104： 同場景一，停 102 -> rsync 拷貝至 104 -> 掛在 101 下同步追平 -> 驗證 -> 切 102 讀流量至 104。
2. 建立新主 103： 利用 102 數據 (或 104) rsync 至 103 -> 掛在 101 下做從庫 -> 追平同步。
3. 核心反向操作 (將 104 變為 103 的從庫)：

   -- 在 104 上
   STOP SLAVE;
   -- 在 103 上
   STOP SLAVE IO_THREAD;
   STOP SLAVE SQL_THREAD; -- 記住 Master_Log_File, Read_Master_Log_Pos (即 Exec_Master_Log_Pos)
   -- 在 104 上 追趕到 103 當前位點
   START SLAVE UNTIL MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;
   STOP SLAVE;
   RESET SLAVE ALL; -- 清除舊主 101 信息
   -- 在 103 上
   SHOW MASTER STATUS; -- 記錄 File, Position
   GRANT REPLICATION SLAVE ON *.* TO 'repl'@'104' IDENTIFIED BY 'pass';
   -- 在 104 上
   CHANGE MASTER TO MASTER_HOST='103', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;
   -- 重啟 104 MySQL (關鍵：RESET SLAVE ALL 後 Master_Server_Id 需重啟刷新)
   -- 檢查 104 IO/SQL_THREAD 為 Yes
   -- 在 103 上 START SLAVE;
   

4. 最終切換 (業務低峰，嚴禁寫入舊主)：

   -- 101 鎖表停寫
   FLUSH TABLES WITH READ LOCK;
   -- 確認 103 同步延遲為 0
   -- 研發切寫流量至 103，讀流量至 104
   UNLOCK TABLES; (101)
   -- 斷開 103 -> 101 同步關係 (STOP SLAVE; RESET SLAVE ALL;)
   

避坑指南： 切換寫入時務必 FLUSH TABLES WITH READ LOCK 確保 101 靜止；RESET SLAVE ALL 後必須重啟 MySQL 以刷新 Master_Server_Id；全程監控 Seconds_Behind_Master。

場景五：雙主跨機房架構 —— 單邊主庫替換 (磁盤擴容/機器更換)

架構： A機房 1.101<->1.102 雙主同步 B機房 2.101<->2.102。需替換 A 機房主從為 1.103/1.104，保持雙主關係。

1. 搭建 A 機房新主從： 1.103/1.104 建立主從 (1.103主)。
2. 數據同步： 停 1.102 -> rsync 拷貝至 1.103 -> 掛在 1.101 下同步追平 -> 驗證。
3. 建立 1.104 從庫： 同步 1.103 數據至 1.104。
4. 建立跨機房雙主： 參考場景四「反向操作」，將 1.103 掛在 2.101 下做從庫同步追平，再配置 2.101 為 1.103 的從庫，雙向同步建立 (需關閉 log_slave_updates 避免循環，或配置 auto_increment_offset/increment 區分奇偶)。
5. 切換： 研發切 A 機房寫入至 1.103，讀至 1.104。下線 1.101/1.102。

跨機房難點： 網絡延遲導致同步延遲大，需預留足夠追趕時間；雙主 auto_increment 奇偶配置必須與舊主一致；log_slave_updates=ON 是雙主傳遞 binlog 的前提。

場景六：多實例跨機房遷移 —— 數據修復/實例替換 (含同步過濾)

架構： 1.113 (7936實例) 遷移至 2.117 (新建 7938, 7939 實例)。業務特點：部分庫只在 A 地寫，部分只在 B 地寫，涉及 replicate-ignore-db / replicate-wild-do-table 過濾規則。

1. 備份帶位點： 1.113 使用 innobackupex --slave-info --databases='db1,db2' 備份指定實例。
2. 傳輸恢復： 壓縮包傳至 2.117 -> innobackupex --apply-log -> innobackupex --copy-back。
3. 配置過濾與唯一性： 修改 2.117 配置：replicate-ignore-db, replicate-wild-do-table, innodb_file_per_table=1, read_only=1, 唯一 server_id。
4. 建立同步： 1.112 授權 -> 2.117 CHANGE MASTER TO ... MASTER_LOG_FILE, MASTER_LOG_POS (參考 xtrabackup_slave_info 文件) -> START SLAVE。
5. 多實例部署： 同法建立 7939 實例，調整過濾規則。
6. 驗證切換： 數據核對 + 權限核對 -> 研發切業務至新實例。

遷移鐵律：14 條必須銘記的注意事項

1. Event Scheduler： 遷移涉及定時任務時，目標主庫必須開啟 event_scheduler=ON。
2. 全鏈路監控： 磁碟空間、網絡抖動、主從延遲、業務錯誤率、慢查詢，全程不可盲區。
3. 位點不容差錯： CHANGE MASTER TO 的 MASTER_LOG_FILE/POS 一旦出錯，必導致數據不一致，三核對再執行。
4. 腳本執行目錄： 操作腳本放在數據目錄，而非 $HOME，避免相對路徑災難。
5. 自動化謹慎用： 腳本必頀經過預演環境驗證，切勿「弄巧成拙」。
6. 三思而後行： 每條命令執行前確認參數含義，rm -rf 類操作雙人複核。
7. 多實例關停： 必須用 mysqladmin -S /tmp/mysql_3306.sock shutdown 指定 Socket，防誤關其他實例。
8. 從庫唯讀： 強制 read_only=1 (超級用戶除外)，防誤寫入導致主從斷裂。
9. Server ID 全局唯一： 所有節點 (含備庫、新庫) server_id 必須唯一，否則同步報錯。
10. 過濾規則精準配： replicate-ignore-db (庫級) 與 replicate-wild-do-table (表級) 邏輯勿混淆，測試驗證。
11. 獨立表空間強制開： 新建實例必設 innodb_file_per_table=1，避免 ibdata1 膨脹導致備份傳輸極慢。
12. 壓縮陷阱： gzip 壓縮完成會刪除源文件，備份文件傳輸前確認是否需要保留原檔。
13. 嚴禁主庫操作： 所有備份、拷貝、DDL 均在從庫/備庫執行，主庫只做授權、鎖表切流量。
14. MyISAM 兼容性： xtrabackup 會鎖 MyISAM 表，遷移前務必掃描 SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE='MyISAM'，轉 Engine 或單獨處理。

DBA 實戰寶典：8 個提效技巧

1. 位點取值金標準： Relay_Master_Log_File (主庫 Binlog 文件) + Exec_Master_Log_Pos (SQL 線程已執行位點)，而非 Master_Log_File / Read_Master_Log_Pos (IO 線程讀到位點)。
2. rsync 神組合： rsync -avhW --no-compress --progress | expect -c "spawn ...; interact" & nohup，斷點續傳、免密、後台、進度可視。
3. 備份邊壓縮： innobackupex --stream=xbstream --compress /backup | gzip > backup.xb.gz，落盤即壓縮，節省 IOPS。
4. 限流備份： --throttle=100 (每秒 10MB) 保護業務 IO；--parallel=4 加速 (配合 --stream 時無效)。
5. 清單化作業： 遷移前列 Checklist、畫流程圖、預寫所有命令，心中有數手中有單。
6. 本地極速拷貝： rsync -avhW --no-compress --progress /src/ /dst/ 比 cp 快且可斷點續傳。
7. 跨機房大數據傳輸： 物理硬碟快遞 (AWS Snowball 模式) 帶寬無上限，延遲為零，TB/PB 級首選。
8. 異地備份策略： 異地備份不僅是備份，更是災難恢復演練的素材，定期演練恢復流程 (RTO/RPO 量化)。

總結：遷移的本質是「秩序重建」

回顧全文，MySQL 遷移的核心邏輯可歸納為三層：

1. 目的層： 業務零感知、平穩持續運行 (RTO 最小化, RPO=0)。
2. 技術層： 主從同步鏈路的延續與重構 (GTID/位點對齊、反向切換、過濾規則傳遞)。
3. 協作層： 權限一致性、讀寫分離切換順序、跨機房延遲評估、研發配合驗證回滾預案。

工具與命令會迭代 (如 xtrabackup 逐漸被 MySQL Shell / Mydumper 替代，GTID 取代文件位點)，但「備份->傳輸->恢復->同步追趕->驗證->切換->觀察」的工程化閉環思維永遠不變。正如文末所言：「證明自己有能力最重要的一點，就是讓一切都在自己的掌控之中。」