| 工具 | 類型 | 引擎支援 | 鎖表影響 | 恢復速度 | 適用場景 |
|---|---|---|---|---|---|
| mysqldump | 邏輯備份 | 所有 | FTWRL (全表寫鎖) 或 --single-transaction | 慢 (SQL 重放) | 小數據量、跨版本遷移、結構導出 |
| XtraBackup | 物理熱備 | InnoDB/XtraDB (MyISAM 需短暫鎖) | 無鎖 (InnoDB) | 極快 (檔案複製+Redo重放) | 大數據量生產備份、主從搭建、PITR |
| 企業版 MEB | 物理熱備 | 所有 | 無鎖 | 極快 | 商業支援環境 |
xtrabackup 內建 --backup 等參數，逐步取代 innobackupex
參數 作用 典型值 --user備份用戶 (需 RELOAD、LOCK TABLES、REPLICATION CLIENT、PROCESS、SUPER) backup_user --password密碼 --defaults-fileMySQL 配置文件路徑 (關鍵：讀取 datadir、innodb_data_file_path 等) /etc/my.cnf --no-timestamp不在備份目錄加時間戳，便於腳本指定固定路徑 --incremental標識增量備份 --incremental-basedir增量基準目錄 (全量或上級增量) /backup/full --redo-only準備階段僅應用 Redo Log，不回滾未提交事務 (增量鏈中間節點必加) --apply-log準備階段：應用 Redo Log、生成 .ibd 可用文件 --copy-back恢復階段：將備份文件複製回目標 datadir --parallel並行複製/壓縮線程數 4-8 --compress備份時壓縮 (需準備階段 --decompress) --encrypt備份時加密 (AES) 實戰演練：全量 + 兩級增量 + 恢復驗證
環境：MySQL 5.6.14、數據目錄 /usr/local/mysql/data
1. 全量備份 (Base)
mysql -e "CREATE DATABASE biz1; USE biz1; CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(20)); INSERT INTO t1 VALUES (1,'A'),(2,'B');"
3. 第一次增量備份 (Inc1)
mysql -e "CREATE DATABASE biz2; USE biz2; CREATE TABLE t2 (id INT PRIMARY KEY, val INT); INSERT INTO t2 VALUES (1,100),(2,200);"
5. 第二次增量備份 (Inc2) - 基於 Inc1
systemctl stop mysqld
rm -rf /usr/local/mysql/data/*
7. 恢復準備階段 (關鍵順序)
8. 恢復複製階段
9. 權限修正與啟動驗證
生產級備份策略設計
現象 原因 解決 備份失敗: "Can't create test file" datadir 權限/路徑錯誤 檢查 --defaults-file 指定正確、mysql 用戶可寫 datadir 增量備份 LSN 不連續 基準目錄錯誤/跳過增量 嚴格遵循 Full → Inc1 → Inc2 鏈路，檢查 xtrabackup_checkpoints 準備階段報錯 "Log sequence number is in the future" MySQL 版本不匹配/數據目錄損壞 確保備份與恢復環境 MySQL 大版本一致 (5.6↔5.6) 恢復後啟動報錯 "Unknown/unsupported storage engine: InnoDB" 未複製 ibdata1/redo log/系統表空間 檢查 --copy-back 輸出、確認 datadir 完整 備份佔用過多磁盤 IO 影響業務 並行度過高/無限流 調整 --parallel、使用 ionice -c2 -n7、限制磁盤配額 總結
Percona XtraBackup 是 MySQL 物理熱備份的**事實標準**。掌握 全量 → 增量鏈 → --redo-only 準備 → --copy-back 恢復 核心流程，配合 並行、壓縮、加密、異地同步、定期演練，構建企業級備份體系。關鍵成功因素：**版本一致、LSN 鏈完整、準備階段順序正確、權限修正、驗證不可少**。
