MySQL 備份與恢復 基礎概念

一、簡介

數據無價，MySQL做爲一個數據庫系統，其備份天然也是很是重要且有必要去作。備份的理由千千萬，預防故障，安全需求，回滾，審計，刪了又改的需求等等，備份的重要性不言而喻。除了備份自己，如何使用備份來恢復服務也是一項重點內容，不能用來恢復的備份沒有意義。本文主要會針對備份和恢復這兩方面作一些簡單的介紹。

本文爲《高性能MySQL》備份相關章節的讀書筆記。

二、備份和恢復的簡單定義

正如簡介所說，備份人盡皆知，也很容易引發人的重視。根據需求寫按期腳本，或者使用其餘方式都是比較常見的。可是恢復就沒有那麼引人注目了。好比說，也許會每週/天天按期進行自動備份。可是多久會進行一次備份的恢復測試？備份的內容是否完成？是否可用於恢復？若是出現故障，恢復的流程是否易操做？
備份只是數據源，如何使用數據源，完全恢復系統這個過程。也很是重要。備份與恢復，都是MySQL運維中須要掌握的內容。

備份的意義在於恢復。若是不能恢復，那就不叫備份（好比RAID陣列不是備份，若是DROP DATABASE，RAID陣列不能恢復）

[還原] 和 [恢復] 的區別：

• 還原：僅指將備份文件中的內容提取出來並加載。
• 恢復：包括還原備份文件在內的一系列措施，目的是讓服務恢復正常運行，好比重啓MySQL，修改配置等其餘操做。

也就是說，恢復是要恢復到異常出前，採起的全部操做(好比修改參數，重啓服務等)。不只僅只是還原備份。

三、恢復計劃須要考慮的幾個因素

恢復計劃在設計的時候，須要考慮一些因素，從而根據不一樣的需求進行更好的規劃。能夠根據RPO(恢復點目標)和RTO(恢復時間目標)這兩個需求來協助制定合適的恢復策略。

• RPO(恢復點目標)：能夠容忍丟失多少數據？(須要恢復全部數據，仍是能容忍上一次備份以來的數據丟失？)
• RTO(恢復時間目標)：須要等待多久將數據恢復？(用戶能接受到什麼程度)

也許還需考慮：須要恢復什麼？(整個服務器，單個庫，單個表，仍是事務)

其次，恢復計劃須要按期進行測試，抽出數據測試備份確實有效、實際進行一次完整的備份恢復，熟悉整個恢復流程，確保真正發生問題時，能夠有條不紊的完成恢復。

四、備份

4.一、備分內容包括什麼？

最簡單的策略就是只備份數據和表定義。可是恢復數據庫須要更多內容，若是能備份的越充足，那麼恢復起來也就更容易。（主要仍是根據需求）

好比能夠根據實際狀況，考慮備份以下內容：
一、Binlog和InnoDB事務日誌。
二、主/從庫配置文件。
三、數據庫操做系統配置(cron、腳本、內核參數)

或者說，根據須要進行備分內容的擴展。若是對於數據庫恢復、甚至重建有很高需求(好比要求更快恢復)，那麼備份更多的內容也必不可少。若是須要有從0恢復數據庫的能力，那須要作更多工做。

4.二、物理備份與邏輯備份

備份種類	邏輯備份	物理備份
簡介	利用mysqldump等命令實現備份	直接複製數據庫文件
優勢	能夠文本編輯，恢復簡單，使用mysqldump備份靈活。	足夠直觀，備份和恢復過程，本質上就是文件的移動。恢復速度更快。MySQL服務器幾乎不須要執行操做。
缺點	備份和恢復都須要MySQL服務參與、且佔用CPU資源。有可能很慢	InnoDB的原始文件一般比邏輯備份大得多。

物理備份和邏輯備份的一點抉擇：

• 對於大數據庫，必須有物理備份。邏輯備份太慢，也可考慮基於快照的備份作輔助。
• 對於小數據庫，邏輯備份幾乎就能夠了。

物理備份簡單高效，邏輯備份儘可能也要作。【二者都要有，看具體需求和資源分配】
其次：除非通過測試，不然不能假設備份可用。好比使用 mysqlcheck -A 測試數據庫。

4.三、Binlog備份

Binlog也是備份中的重要一環，由於基於時間點的恢復須要用到它。並且Binlog通常很小，頻繁的備份也較容易實現。若是有某個時間點的數據備份，加上自那之後的全部Binlog，就能夠回滾全部變更。

4.3.一、備份Binlog的一些策略

• 建議expire_logs_days設置的儘可能長，至少超過2次最近的全備份。
• 備份Binlog時，可使用FLUSH LOGS建立新的Binlog（這樣就只須要備份最新的Binlog了） 
• 能夠考慮將數據和Binlog分開保存，避免同時丟失。
• 能夠選擇常常備份Binlog或者配置一個 --log_slave_updata的只讀備庫。

須要注意的是，expire_log_days是經過 日誌文件的修改時間來判斷的，而不是內容。（若是一直只有一個Binlog文件，可能就不會清理）。因此必定要使用 FLUSH LOGS按期刷新Binlog。

4.3.二、老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.三、Binlog備份的幾點注意事項

• 增加保存時間只是一種配置，不表明Binlog自己就不須要備份。Binlog仍然須要按期備份，以即可以結合最近的備份使用。
• 須要注意的是，從庫也使用Binlog。因此須要區分從庫和備份的Binlog管理。

4.四、增量備份與差別備份

增量備份：自任意類型備份後，改動的全部內容的備份。
差別備份：特指自上次全備份以後，改動的全部內容的備份。

也就是說，差別備份基於全備份。而增量備份基於任意備份(好比某一個指定的差別備份。
下面舉一個例子：週日進行一次全備份，週一針對週日的全備份作一次差別備份。週二開始就能夠有兩種選擇：一、基於週日的全備份作備份(差別)。二、基於週一的差別備份作備份(增量)

差別備份可選項：

• 不要備份沒有改變的表。
• 不要備份沒有改變的行

雖然這樣作差別備份能夠提升恢復速度。可是全備份仍是頗有必要的。( 全備份能夠頻率低，可是必須有)。

4.五、從庫備份

在從庫中備份，有時候是一個可選項，不會干擾到主庫，避免給主庫增長更多的負載。其次，當計劃從從庫備份的時候，要保存更多信息，好比從庫相對於主庫的位置(偏移)等。

首先 從庫不等於備份，從庫和主庫數據不匹配是很常見的。其次、從從庫備份確實能夠減輕主庫備份時的負載，可是不夠好。穩定起見，仍是建議進行主庫備份、全備份。

4.六、其餘注意事項

4.6.一、在線備份與離線備份
離線備份是最簡單最安全的。也是一致性最好的。問題就是，大部分數據庫不能接受停機備份。因此基本仍是用在線備份，或者說不停機備份

能夠考慮在業務低峯期進行在線備份，即便負載增大也不會有太大影響。

4.6.二、數據一致性
數據一致性：對於多個表之間數據的一致性要求。（好比兩個邏輯相關的操做分在了兩個事務內，而備份在兩個事務之間執行，就會致使數據不一致）
InnoDB能夠在轉儲一組相關表的時候，開始一個事務，這樣能夠很大程度上保證數據的一致性。

可是也要注意，若是事務設置的不合理，好比一組相關表的修改分在了兩個事務內，這仍然會致使數據不一致。（ 一組表的相關操做須要確保在一個事務內)

4.6.三、按期進行備份恢復測試，確認整個恢復過程須要的資源
能恢復的備份纔有價值，不是有備份就能夠

小結

本文講解了一些備份的基本知識和概念，包括一些基本概念、恢復的重要性、備份和恢復的簡單策略。還說起到了備分內容的選擇、差別/增量備份、Binlog備份等。後續還須要繼續學習，瞭解備份和恢復的具體操做方法和實踐。