淺析MySQL 備份與恢復
1、簡介
資料無價，MySQL作為一個數據庫系統，其備份自然也是非常重要且有必要去做。備份的理由千千萬，預防故障，安全需求，回滾，審計，刪了又改的需求等等，備份的重要性不言而喻。除了備份本身， 如何使用備份來恢復 服務也是一項重點內容，不能用來恢復的備份沒有意義。本文主要會針對備份和恢復這兩方面做一些簡單的介紹。
本文為《高效能MySQL》備份相關章節的讀書筆記。
2、備份和恢復的簡單定義
正如簡介所說，備份人盡皆知，也很容易引起人的重視。根據需求寫定期指令碼，或者使用其他方式都是比較常見的。但是恢復就沒有那麼引人注目了。比如說，也許會每週/每天定期進行自動備份。但是多久會進行一次備份的恢復測試？備份的內容是否完成？是否可用於恢復？如果出現故障，恢復的流程是否易操作？
備份只是資料來源， 如何使用資料來源 ， 徹底恢復系統 這個過程。也非常重要。備份與恢復，都是MySQL運維中需要掌握的內容。
備份的意義在於恢復。如果不能恢復，那就不叫備份（比如RAID陣列不是備份，如果DROP DATABASE，RAID陣列不能恢復）
[還原] 和 [恢復] 的區別：
- 還原：僅指將備份檔案中的內容提取出來並載入。
- 恢復：包括還原備份檔案在內的一系列措施，目的是讓服務恢復正常執行，比如重啟MySQL，修改配置等其他操作 。
也就是說，恢復是要恢復到異常出前，採取的所有操作(比如修改引數，重啟服務等)。不僅僅只是還原備份。
3、恢復計劃需要考慮的幾個因素
恢復計劃在設計的時候，需要考慮一些因素，從而根據不同的需求進行更好的規劃。可以根據RPO(恢復點目標)和RTO(恢復時間目標)這兩個需求來協助制定合適的恢復策略。
- RPO(恢復點目標)：可以容忍丟失多少資料？(需要恢復所有資料，還是能容忍上一次備份以來的資料丟失？)
- RTO(恢復時間目標)：需要等待多久將資料恢復？(使用者能接受到什麼程度)
也許還需考慮：需要恢復什麼？(整個伺服器，單個庫，單個表，還是事務)
其次，恢復計劃需要定期進行測試，抽出資料測試備份確實有效、實際進行一次完整的備份恢復，熟悉整個恢復流程，確保真正發生問題時，可以有條不紊的完成恢復。
4、備份
4.1、備份內容包括什麼？
最簡單的策略就是 只備份資料和表定義 。但是恢復資料庫需要更多內容，如果能備份的越充足，那麼恢復起來也就更容易。（主要還是 根據需求 ）
比如可以根據實際情況，考慮備份如下內容：
1、Binlog和InnoDB事務日誌。
2、主/從庫配置檔案。
3、資料庫作業系統配置(cron、指令碼、核心引數)
或者說，根據需要進行備份內容的擴充套件。如果對於資料庫恢復、甚至重建有很高需求(比如要求更快恢復)，那麼備份更多的內容也必不可少。如果需要有從0恢復資料庫的能力，那需要做更多工作。
4.2、物理備份與邏輯備份
| 備份種類 | 邏輯備份 | 物理備份 |
|---|---|---|
| 簡介 | 利用mysqldump等命令實現備份 | 直接複製資料庫檔案 |
| 優點 | 可以文字編輯，恢復簡單，使用mysqldump備份靈活。 | 足夠直觀，備份和恢復過程，本質上就是檔案的移動。恢復速度更快。MySQL伺服器幾乎不需要執行操作。 |
| 缺點 | 備份和恢復都需要MySQL服務參與、且佔用CPU資源。有可能很慢 | InnoDB的原始檔案通常比邏輯備份大得多。 |
物理備份和邏輯備份的一點抉擇：
- 對於大資料庫，必須有物理備份。邏輯備份太慢，也可考慮基於快照的備份做輔助。
- 對於小資料庫，邏輯備份幾乎就可以了。
物理備份簡單高效，邏輯備份儘量也要做。【兩者都要有，看具體需求和資源分配】
其次：除非經過測試，否則不能假裝置份可用。比如使用 mysqlcheck -A 測試資料庫。
4.3、Binlog備份
Binlog也是備份中的重要一環，因為基於時間點的恢復需要用到它。而且Binlog一般很小，頻繁的備份也較容易實現。如果有某個時間點的資料備份，加上自那以後的所有Binlog，就可以回滾所有變動。
4.3.1、備份Binlog的一些策略
FLUSH LOGS --log_slave_updata
需要注意的是，expire_log_days是通過 日誌檔案的修改時間 來判斷的，而不是內容。（如果一直只有一個Binlog檔案，可能就不會清理）。所以一定要使用 FLUSH LOGS 定期重新整理Binlog。
4.3.2、老Binlog的清理
最好使用expire_log_days來進行自動的清理，保留一定天數。如果需要用cron清理。那麼 不要使用 find+rm配置的cron清理日誌。
0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rm
使用如下cron代替：
0 3 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
4.3.3、Binlog備份的幾點注意事項
- 增長儲存時間只是一種配置，不代表Binlog本身就不需要備份。Binlog仍然需要定期備份，以便可以結合最近的備份使用。
- 需要注意的是，從庫也使用Binlog。所以需要 區分從庫和備份的Binlog管理 。
4.4、增量備份與差異備份
增量備份：自任意型別備份後，改動的所有內容的備份。
差異備份：特指自上次 全備份 之後，改動的所有內容的備份。
也就是說，差異備份基於全備份。而增量備份基於任意備份(比如某一個指定的差異備份。
差異備份可選項：
- 不要備份沒有改變的表。
- 不要備份沒有改變的行
雖然這樣做差異備份可以提高恢復速度。但是全備份還是很有必要的。( 全備份可以頻率低，但是必須有 )。
4.5、從庫備份
在從庫中備份，有時候是一個 可選項 ，不會干擾到主庫，避免給主庫增加更多的負載。其次，當計劃從從庫備份的時候，要儲存更多資訊，比如從庫相對於主庫的位置(偏移)等。
首先 從庫不等於備份 ，從庫和主庫資料不匹配是很常見的。其次、從從庫備份確實可以減輕主庫備份時的負載，但是不夠好。穩定起見，還是建議進行主庫備份、全備份。
4.6、其他注意事項
4.6.1、線上備份與離線備份
離線備份是最簡單最安全的。也是一致性最好的。問題就是，大部分資料庫不能接受停機備份。所以基本還是用線上備份，或者說不停機備份
可以考慮在業務低峰期進行線上備份，即使負載增大也不會有太大影響。
4.6.2、資料一致性
資料一致性：對於多個表之間資料的一致性要求。（比如兩個邏輯相關的操作分在了兩個事務內，而備份在兩個事務之間執行，就會導致資料不一致）
InnoDB可以在轉儲一組相關表的時候，開始一個事務，這樣可以很大程度上保證資料的一致性。
但是也要注意，如果事務設定的不合理，比如一組相關表的修改分在了兩個事務內，這仍然會導致資料不一致。（ 一組表的相關操作需要確保在一個事務內 )
4.6.3、定期進行備份恢復測試，確認整個恢復過程需要的資源
能恢復的備份才有價值，不是有備份就可以
小結
本文講解了一些備份的基本知識和概念，包括一些基本概念、恢復的重要性、備份和恢復的簡單策略。還提及到了備份內容的選擇、差異/增量備份、Binlog備份等。後續還需要繼續學習，瞭解備份和恢復的具體操作方法和實踐。
以上就是淺析MySQL 備份與恢復的詳細內容，更多關於MySQL 備份與恢復的資料請關注我們其它相關文章！