MySQL 備份原理深度解析：邏輯備份 vs 物理備份 vs 快照備份

備份核心指標

• RPO（恢復點目標）：能恢復到什麼程度（數據丟失量）
• RTO（恢復時間目標）：恢復需要多長時間

方案一：冷備份（停服拷貝）

關閉 MySQL → 拷貝 datadir → 恢復時直接覆蓋。

生產環境幾乎不可用（需停服），僅適合離線維護窗口。

方案二：快照備份（LVM）

原理： 文件系統層面 Copy-on-Write，類似 InnoDB MVCC 但作用於塊設備。

• 需所有數據文件、日志在同一邏輯卷
• 快照區保存快照點開始的舊數據塊
• 優點：秒級完成、對業務幾乎無影響
• 缺點：本地磁盤故障快照同損、不支持跨機器直接恢復

方案三：邏輯備份

mysqldump（官方單線程）

關鍵參數：

• --single-transaction：啟動事務獲取一致性視圖（僅 InnoDB 有效）
• --master-data=2：記錄 Binlog 位點（CHANGE MASTER TO 註釋）

執行流程：

1. FLUSH TABLES WITH READ LOCK (FTWRL) 全局讀鎖
2. 開啟快照讀（InnoDB 一致性視圖）
3. 備份非 InnoDB 表（.frm/.MYD/.MYI）
4. 釋放 FTWRL
5. 逐表備份 InnoDB 表（利用 MVCC 保證一致性）
6. 5.6+ 使用 Savepoint 機制，逐表釋放 MDL 鎖

mydumper（社區多線程）

• 多線程並行導出，速度提升數倍
• 核心難點：多線程一致性位點獲取
• 解決：FTWRL 持有期間，所有線程獲取同一 Binlog 位點

方案四：物理備份（Xtrabackup / innobackupex）

原理： 直接拷貝數據文件 + Redo Log，速度最快。

innobackupex 流程：

1. 啟動 Redo Log 拷貝線程（從最新 Checkpoint 開始）
2. 啟動 .ibd 文件拷貝線程
3. 拷貝結束 → FTWRL 獲取一致性位點
4. 備份非 InnoDB 表 + .frm 文件
5. 等待 Redo Log 追趕完畢（此時無新事務提交）
6. 記錄 Binlog 位點 → 釋放鎖 → 備份完成

Xtrabackup 改進：BACKUP LOCKS（Percona）

解決 FTWRL 鎖表時間長、阻塞 DML、導致主備延遲的問題：

方案選型建議

核心原則： 任何備份未經恢復演練都不算備份。建立定期恢復演練機制，驗證 RPO/RTO 達標。