文章來源地址http://www.zghlxwxcb.cn/news/detail-710026.html

1.?每個人都知道需要備份，但并不是每個人都能意識到需要的是可恢復的備份

1.1.?如果你沒有提前做好備份規(guī)劃，也許以后會發(fā)現(xiàn)已經(jīng)錯失了一些最佳的選擇

1.2.?在服務器已經(jīng)配置好以后，才想起應該使用LVM，以便獲取文件系統(tǒng)的快照——但這時已經(jīng)太遲了

1.3.?如果你沒有計劃做定期的恢復演練，當真的需要恢復時，就會發(fā)現(xiàn)并沒有那么順利

2.?不要掉進副本就是備份的陷阱

2.1.?副本對生成備份而言是一個干涉較少的源，但它不是備份本身

2.2.?確保備份可以通過DROP TABLE測試

2.2.1.?“遭受黑客攻擊”的測試

2.2.2.?能通過數(shù)據(jù)中心失敗的測試

2.2.3.?如果是基于備庫生成備份，需要通過從源重建備份，并從那時起強制執(zhí)行super_read_only來確保你的所有副本是一致的

3.?裸文件備份

3.1.?物理備份

3.2.?文件系統(tǒng)中的文件副本

4.?邏輯備份

4.1.?重建數(shù)據(jù)所需的SQL語句

5.?推薦的備份方式

5.1.?Percona XtraBackup進行裸文件備份

5.2.?mydumper進行邏輯備份

5.3.?無侵入地實現(xiàn)二進制的原始數(shù)據(jù)備份

5.3.1.?備份可以通過啟動mysqld實例檢查所有的表來進行驗證

5.3.2.?建議備份二進制日志

5.3.2.1.?盡可能久地保留多份備份的數(shù)據(jù)和二進制文件

5.3.2.2.?即使最近的備份無法使用，還可以使用較老的備份來執(zhí)行恢復或者創(chuàng)建新的副本

6.?整體備份和恢復策略要點

6.1.?安全

6.1.1.?訪問備份的入口

6.1.2.?恢復數(shù)據(jù)的權限

6.1.3.?文件是否需要加密

6.2.?備份存儲在哪里

6.2.1.?離源數(shù)據(jù)多遠

6.2.1.1.?在一塊不同的磁盤上

6.2.1.2.?一臺不同的服務器上

6.2.1.3.?離線存儲

6.2.2.?如何將數(shù)據(jù)從源頭移動到目的地

6.3.?保留策略、審計、法律要求，以及相關的條款

6.4.?存儲解決方案和介質(zhì)，壓縮，以及增量備份

6.5.?存儲的格式

6.6.?對備份的監(jiān)控和報告

6.7.?存儲層內(nèi)置備份功能

6.7.1.?其他專用設備

7.?熱備份

7.1.?不需要任何的服務停機時間

8.?還原

8.1.?從備份文件中獲取數(shù)據(jù)，可以將這些文件加載到MySQL里，也可以將這些文件放置到MySQL期望的路徑中

9.?恢復

9.1.?當某些異常發(fā)生后對一個系統(tǒng)或其部分的拯救

9.2.?從備份中還原數(shù)據(jù)

9.3.?使服務器完全恢復功能的所有必要步驟

9.4.?存儲引擎的崩潰恢復要求數(shù)據(jù)和日志文件一致

9.4.1.?要確保數(shù)據(jù)文件中只包含已經(jīng)提交的事務所做的修改，恢復操作會將日志中還沒有應用到數(shù)據(jù)文件的事務重新執(zhí)行

10.?備份的理由

10.1.?災難恢復

10.1.1.?硬件故障

10.1.2.?一個不經(jīng)意的Bug導致數(shù)據(jù)損壞

10.1.3.?服務器及其數(shù)據(jù)由于某些原因不可獲取或無法使用

10.1.4.?某人偶然連錯服務器執(zhí)行了一個ALTER TABLE操作

10.1.5.?機房大樓被燒毀

10.1.6.?惡意的黑客攻擊

10.2.?人們改變想法

10.2.1.?經(jīng)常會在刪除某些數(shù)據(jù)后又想恢復這些數(shù)據(jù)

10.3.?審計

10.3.1.?需要知道數(shù)據(jù)或Schema在過去的某個時間點是什么樣的

10.4.?測試

10.4.1.?最簡單的基于實際數(shù)據(jù)來測試的方法是，定期用最新的生產(chǎn)環(huán)境數(shù)據(jù)更新測試服務器

10.4.2.?只要把備份文件還原到測試服務器上即可

11.?備份誤區(qū)

11.1.?復制就是備份

11.1.1.?復制不是備份

11.1.2.?使用RAID陣列也不是備份

11.1.3.?不是備份，也不是備份的替代品

11.2.?快照就是備份

11.2.1.?無論是LVM、ZFS還是SAN快照，都不是真正的備份

11.2.1.1.?不包含數(shù)據(jù)的完整副本

11.2.2.?快照是寫時復制

11.2.2.1.?只包含數(shù)據(jù)的實時副本與快照發(fā)生時的數(shù)據(jù)之間的差異

11.2.3.?如果備份是用于某些特殊用戶的，那么快照可能是一個非常好的方法

12.?定義恢復需求

12.1.?備份在先

12.1.1.?只有已經(jīng)做了備份才可能恢復，因此在構建系統(tǒng)時，注意力自然會集中在備份上

12.2.?備份由腳本和任務自動完成

12.3.?備份是日常任務，但恢復常常發(fā)生在危急情形下

12.4.?安全的需要

12.4.1.?做異地備份，可能需要對備份數(shù)據(jù)進行加密，或采取其他措施來進行保護

12.5.?需要培養(yǎng)幾個人并有計劃地讓他們互為備份，這樣就無須由一個不合格的人來恢復數(shù)據(jù)

12.6.?恢復點目標（PRO）

12.7.?恢復時間目標（RTO）

13.?備份方案

13.1.?備份僅是數(shù)據(jù)的一個副本，但是受限于應用程序的要求、MySQL的存儲引擎架構，以及系統(tǒng)配置等因素，復制一份數(shù)據(jù)變得很困難

13.2.?對數(shù)據(jù)丟失的承受力越強，備份越簡單

13.2.1.?一個“寬松”的基于故障時間點的恢復需求意味著需要重建數(shù)據(jù)，直到“足夠接近”問題發(fā)生的時刻

13.2.2.?一個“硬性”的需求意味著不能容忍丟失任何一個已提交的事務，即使某些可怕的事情發(fā)生（例如，服務器著火了）

13.2.2.1.?將二進制日志保存在一個獨立的SAN卷

13.2.2.2.?使用DRBD磁盤復制

13.3.?在生產(chǎn)實踐中，對于大數(shù)據(jù)庫來說，裸文件備份是必需的：邏輯備份太慢并受到資源限制，從邏輯備份中恢復需要很長時間

13.3.1.?基于快照的備份，例如Percona ??XtraBackup和MySQL ?EnterpriseBackup，是最好的選擇

13.3.2.?對于較小的數(shù)據(jù)庫，邏輯備份可以很好地勝任

13.4.?保留多個備份集

13.5.?定期從邏輯備份（或者裸文件備份）中抽取數(shù)據(jù)進行恢復測試

13.6.?保存二進制日志用于基于故障時間點的恢復

13.6.1.?將expire_logs_days參數(shù)的值設置得足夠大，至少確保可以從最近兩次裸文件備份中做基于時間點的恢復

13.6.2.?保持源運行且不應用任何二進制日志的情況下創(chuàng)建一個副本

13.6.3.?使備份二進制日志獨立于過期設置，二進制日志需要保存在備份中足夠長的時間，以便能從最近的邏輯備份中進行恢復

13.6.4.?重放二進制日志來恢復到想要的時間點

13.7.?完全不借助備份工具本身來監(jiān)控備份和備份的過程

13.7.1.?需要額外驗證備份是否正常

13.8.?通過演練整個恢復過程來測試備份和恢復

13.8.1.?測算恢復所需要的資源（CPU、磁盤空間、實際時間，以及網(wǎng)絡帶寬等）

13.9.?考慮安全性

到了這里，關于讀高性能MySQL（第4版）筆記13_備份與恢復（上）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！