MySQL 資料備份神器：mydumper 多線程備份實戰教學

為什麼傳統 mysqldump 已經跟不上時代？

MySQL 官方自帶的 mysqldump 工具雖然普及度極高，但架構上僅支援單線程運作，必須逐張表依序導出，缺乏並行機制。當資料量達到幾十 GB 甚至 TB 級別時，備份耗時極長，嚴重影響業務可用性。

mydumper：為大數據量而生的多線程備份利器

mydumper 是一款開源的高效能邏輯備份工具，核心優勢在於多線程並行處理。它能同時從多張表讀取資料並寫入不同檔案，備份速度較傳統 mysqldump 快 6 倍以上。雖然備份過程需對表加鎖（FTWRL），但現代架構多採用主從複制，備份通常在從庫執行，鎖表影響可忽略不計。

mydumper 核心特性一覽

• 多線程並行備份與恢復
• 支援檔案壓縮（gzip），節省儲存空間
• 自動記錄 binlog 位點（metadata），支援時間點恢復（PITR）
• 守護進程模式：定時快照 + 連續二進制日誌備份
• 支援大表切片（按行數或檔案大小），便於並行導入
• 非事務表（MyISAM）與事務表（InnoDB）一致性快照分離鎖定，縮短全域鎖持有時間

備份機制深度解析

流程關鍵步驟：

1. 主線程執行 FLUSH TABLES WITH READ LOCK，取得全域唯讀鎖
2. 記錄當前 binlog 文件名與位點至 metadata 檔案
3. 啟動 N 個 dump 線程（預設 4），各自開啟 START TRANSACTION WITH CONSISTENT SNAPSHOT
4. 優先導出非 InnoDB 表（MyISAM 等），完成後主線程 UNLOCK TABLES 釋放全域鎖
5. 基於一致性快照並行導出 InnoDB 表
6. 事務提交，產出備份檔案目錄

輸出目錄結構：每張表產生 database.table-schema.sql（結構）與 database.table.sql（資料），啟用切片時會產生多個資料檔。

實戰案例：40GB 核心業務庫跨機器熱備與主從建立

場景：A 業務庫（10.137.143.151，TaeOss，40GB）需熱備至 B 業務機器（10.137.143.152），要求來源端無感知、目標端恢復影響＜1分鐘。

方案選型對比：

• mysqldump：單線程、鎖表久，拒
• xtrabackup：物理備份免鎖，但共享表空間架構下跨機恢復資料不一致、耗時長，拒
• mydumper：多線程邏輯備份、鎖表極短（40GB 約 10 分鐘內）、自帶 binlog 位點，採納

安裝步驟（CentOS 6.4 為例）

# 安裝依賴
yum install glib2-devel mysql-devel zlib-devel pcre-devel
# 編譯安裝
tar zxvf mydumper-0.6.2.tar.gz
cd mydumper-0.6.2
cmake . && make && make install

跨網段遠端備份操作

因生產機為舊版 SuSE Linux，依賴庫複雜且本地備份佔用磁碟 I/O，選擇同網段 CentOS 6.4（10.137.143.156）作為備份跳板機。

# 在 151、152 上授權
mysql -uroot -e "grant all privileges on *.* to 'backup'@'10.137.143.156' identified by 'backup2015';"
mysql -uroot -e "flush privileges;"

mydumper -h 10.137.143.151 -u backup -p backup2015 -B TaeOss -t 8 -o /data/rocketzhang

參數說明：-t 8 8 線程並行，-o 指定輸出目錄。

myloader -h 10.137.143.152 -u backup -p backup2015 -B TaeOss -t 8 -d /data/rocketzhang

# 151 建立 replication 帳號
mysql -uroot -e "grant replication slave on *.* to 'repl'@'10.137.143.152' identified by 'repl123456'; flush privileges;"

# 156 查看 metadata 取得 binlog 位點
cat /data/rocketzhang/metadata
# 輸出範例：binlog file: mysql-bin.002205, position: 456584891

# 152 配置從庫並啟動
vim /etc/my.cnf
# 新增 replicate-do-table = TaeOss.% 等
service mysqld reload
mysql -uroot -e "change master to master_host='10.137.143.151', master_user='repl', master_password='repl123456', master_log_file='mysql-bin.002205', master_log_pos=456584891; start slave; show slave status\G;"

踩坑實錄：主從同步報主鍵衝突 (Error 1062)

經 mysqlbinlog 解析 binlog 定位，發現主庫對 t_evil_detect_uin_blacklist 表的 INSERT 產生主鍵衝突，從庫同步時同樣報錯。

緊急修復方案

1. 從庫導出問題表結構與資料：
   mysqldump -uroot --opt TaeOss t_evil_detect_uin_blacklist > TaeOss.t_evil_detect_uin_blacklist.sql
2. 編輯 SQL 檔，移除 PRIMARY KEY 定義
3. 重新導入，跳過衝突：
   mysql -uroot TaeOss < TaeOss.t_evil_detect_uin_blacklist.sql
4. 重啟同步：stop slave; start slave; show slave status\G;

同步恢復正常。後續需排查主庫為何產生重複主鍵，建議加強應用層冪等性或改用自增主鍵。

總結

mydumper 憑藉多線程並行、短鎖時間、內建 binlog 記錄，成為大數據量 MySQL 邏輯備份的首選。搭配 myloader 平行恢復，能大幅縮短 RTO。生產環境建議：

• 備份在從庫執行，避免主庫鎖表影響業務
• 定期演練恢復流程，驗證 metadata 位點準確性
• 監控備份耗時與檔案完整性，納入巡檢體系