為什麼從二進制日誌恢復這麼慢？

我們有一個啟用了二進制日誌記錄的 MySQL 5.5 伺服器和一個收集二進制日誌的備份腳本，並且每天一次，生成一個完整的數據庫轉儲文件mysqldump。在測試從轉儲和二進制日誌恢復數據庫時，我們發現後者要慢一個數量級。

具體來說：

• 從 92.8 MB 的數據庫轉儲中恢復mysql dbname < dbdump.sql耗時 3m 26.526 秒。
• 從轉儲後恢復所有二進制日誌mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbname需要 38m 10.090s。binlog 文件的總大小為 56.8 MB，輸出的大小mysqlbinlog為 66.4 MB。
• 結合上述兩個步驟，只需從 binlogs 覆蓋的事件花費 2m 15.406s 後進行的 (93.2 MB) 轉儲中恢復。

這個時間差正常嗎？有什麼辦法可以減少嗎？

您必須了解二進制日誌是什麼：它們儲存自記錄以來發生的所有查詢（STATEMENT格式）或行更改（ROW格式）。所以，你的命令：

mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbname

基本上在這近 30 個 binlog 中串列執行伺服器上發生的所有插入、更新和刪除。這就是為什麼從二進制日誌中恢復僅對時間點恢復有用（恢復自上次備份以來的最新更改）。

您可以做一些事情來減少應用程序時間，例如暫時減少數據庫的持久性和一致性約束（因為您總是可以重播這些步驟）- innodb_flush_log_at_trx_commit、禁用二進制日誌、雙重寫入等-或嘗試僅使用 ROW 二進制日誌，這可能會增加磁碟大小，但會使它們更快地應用。

或者，您可以通過創建更頻繁的完整備份（完整備份的大小不是很大）、使用 xtrabackup 等工具創建真正的增量或差異備份來減少必須應用的 binlog 數量，或者使用滯後的從屬伺服器來應對災難恢復。這是因為mysqldump 和 mysqlbinlog 都以邏輯方式恢復數據——物理備份在某些情況下可能更快，特別是對於完全恢復。

顯然，也可能存在特定問題，例如，我有時發現重播LOAD DATA語句比我想像的要慢。

目標是什麼？如果目標是找到恢復系統的路徑，那麼考慮使用複制並擁有一個從站。奴隸通常會與主人在一起。這比你抱怨的 93 分鐘要好得多。

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