大規模備份 MySQL 的良好做法
我是 DB 的新手，尤其是 MySQL 的新手。大規模備份 MySQL 有什麼好的做法嗎？例如，我已經找到了一些東西。
- 使用mysqlbackup（物理備份）而不是mysqldump。
- 將 key_buffer_size 增加到 RAM 的 20%（不僅僅是備份非常有用的選項）。
- 看看maatkit的工具，有一些用於備份。
如果您知道任何用於 MySQL 備份共享的好東西。
不要使用 Maatkit 中的工具。（我寫的。）它們很危險。我在別處寫過這個。 Percona Toolkit是 Maatkit 的替代品，它不包括這些工具。
如果您有 MySQL Enterprise 訂閱，mysqlbackup 非常棒。如果沒有，請考慮 Percona XtraBackup，這是一個幾乎相同的免費工具。
這不是一個愚蠢的問題。您應該認真對待備份。
讓我們看看你的三個選項：
1) Use mysqlbackup (physical backup) instead of mysqldump.MySQL 的企業備份在 Baron Schwartz 中提到過，所以我不再贅述。
2) increase key_buffer_size to 20% of RAM (not just for backup extremely helpful option).key_buffer_size 控制 MyISAM 密鑰緩衝區的大小，用於記憶體 MyISAM 表的索引頁。它們在備份中不起任何作用。例如，如果你使用 mysqldump 和 do
SHOW PROCESSLIST;，你會看到類似
SELECT /* SQL_NO_CACHE */ FROM tblname這可以防止顛簸記憶體。否則，在備份期間，所需的數據將不必要地從 MySQL 的記憶體中推出。
3) take a look at tools of maatkit there are few for backup.Percona 以mk-parallel-dump和mk-parallel-restore為特色。Percona 最近宣布這些工具已棄用。有些人仍然自擔風險使用它們。
實際上，我為數據庫和表編寫了自己的並行轉儲版本，並將算法發佈在 DBA StackExchange中。
Percona 現在有 Percona 工具。它不包括任何備份工具。它作為 XtraBackup 單獨銷售。恕我直言，它有利有弊，但絕對是大型安裝的理想選擇
如果您正在尋找時間點恢復，這並不理想，因為來自 XtraBackup 的備份數據的時間點基於 XtraBackup 完成的時間而不是 XtraBackup 的啟動時間。如果傳入數據的速率幾乎與備份過程本身一樣快，這一點就會很快顯現出來。從理論上講，如果傳入數據的速率與備份過程一樣快或更快，則備份過程將永遠不會完成。早在 2011 年 5 月的 Percona 現場會議上，現場直播就是這樣說的。只要您可以忍受這個和您目前的傳入數據速率，那麼 XtraBackup 就是您的解決方案。