在壓縮數據目錄之前，我執行以下命令：

STOP SLAVE;
FLUSH TABLES WITH READ LOCK;
FLUSH LOGS; 

但是，tar 有時會抱怨在此過程中更新了ibdata*和文件。ib_logfiles*我錯過了什麼？

從機處於冷備用機器中，因此在 tar 執行時沒有客戶端程序在執行。

CentOS release 5.6 64bits, MySQL 5.1.49-log 源碼分發。

FLUSH TABLES WITH READ LOCK不會停止對 InnoDB 的寫入。

• FLUSH TABLES WITH READ LOCK 不適用於InnoDB（MySQL 論壇）
• FLUSH TABLES WITH READ LOCK 如何與 Innodb 表一起使用 (mysqlperformanceblog.com)
• FLUSH TABLES WITH READ LOCK 的速度有多快？(mysqlperformanceblog.com)

它可能會阻止對錶的寫入訪問，但 InnoDB 將允許對 ibdata1 的寫入為重做和撤消日誌提供 MVCC 資訊。

查看 InnoDB 基礎設施地圖

請注意表與 ibdata1 的物理獨立性，以及日誌文件的關聯方式。

由於盒子是奴隸，你有兩個選擇：

選項 #1（熱備份）

• 跑步STOP SLAVE;
• 跑步FLUSH TABLES;
• 執行你的 Linux/tar
• 跑步START SLAVE;

選項#2（完全送出數據的冷備份）

• 跑步SET GLOBAL innodb_fast_shutdown = 0;
• 跑步service mysql stop
• 執行你的 Linux/tar
• 跑步service mysql start

選項#3（冷備份）

• 跑步service mysql stop
• 執行你的 Linux/tar
• 跑步service mysql start

結語

到目前為止，選項#2 和#3 將是更好的選擇。它們之間有什麼區別？

• 選項 #2將所有事務更改從 ibdata1 和事務日誌 ( ib_logfile0, ib_logfile1) 中清除。這使得關機時間更長。但是，您將擁有更快的 mysql 啟動，因為不需要執行 InnoDB 崩潰恢復。
• 選項 #3讓您更快地關閉，讓 InnoDB 處於暫停狀態（ibdata1 和事務日誌 ( ib_logfile0, ib_logfile1) 中的所有事務更改）。事務性更改在 InnoDB 崩潰恢復階段應用於 mysql 啟動。

我相信你可以通過凍結你的文件系統來完成它。

LVM 支持快照，如CentOS 文件和TLDP中所述。

一些儲存模型，如 DELL Equallogic，提供快照支持和 Linux 命令行訪問。你也可以從中受益。

引用自：https://dba.stackexchange.com/questions/29498