MySQL 數(shù)據(jù)庫的備份與恢復

　　數(shù)據(jù)庫的備份與恢復，一直都是DBA最為重要的工作，任何生產(chǎn)環(huán)境的數(shù)據(jù)庫都必須有完整的備份方案與恢復測試。本小節(jié)將主要介紹MySQL的備份與恢復。

　　備份重于一切！備份是DBA最后一根救命稻草……以下幾個是數(shù)據(jù)庫備份的重要理由：災難恢復

　　系統(tǒng)總是要崩潰的，服務器總是要發(fā)生故障的，甚至于機房被燒毀、黑客攻擊，如果發(fā)生這些情況時，沒有有效的備份，只能等死。無錫數(shù)據(jù)恢復操作失誤

　　開發(fā)人員在修改某些數(shù)據(jù)后，發(fā)現(xiàn)操作失誤，需要恢復這些數(shù)據(jù)。DB審計

　　有時候需要知道數(shù)據(jù)庫在過去某個時間點有什么樣的數(shù)據(jù)。測試環(huán)境

　　開發(fā)人員需要定期用最新的生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)恢復至測試環(huán)境，用于開發(fā)驗證。如果有備份，那就很簡單，直接用備份文件還原到測試環(huán)境即可。

　　在規(guī)劃備份和恢復的策略時，有兩個指標需要考量：RPO和RTO。RPO（恢復點目標）： Recovery Point Objective，可以容忍丟多少數(shù)據(jù)RTO（恢復時間目標）： Recovery Time Objective，需要等待多久才將數(shù)據(jù)恢復

　　在定義具體的RPO和RTO時，我們需要明確以下問題：可以容忍丟失多少數(shù)據(jù)？可以容忍多長時間內恢復正常服務？哪種類型的宕機是可以接受的？部分服務不可用是否可以接受？需要恢復什么？單表/部分表？整個數(shù)據(jù)庫？還是整個服務器？

　　將RPO和RTO定義清楚，可以更好地指導備份策略。一般來說，能承受的數(shù)據(jù)丟失越多，備份就越簡單。

　　一個好的備份方案，需要考量以下幾點：對于較大數(shù)據(jù)庫（個人經(jīng)驗是整個數(shù)據(jù)文件大于50GB），物理備份是必須的，備份工具Percona XtraBackup和MySQL Enterprise Backup是比較好的選擇。對于較小的數(shù)據(jù)庫，邏輯備份就可以滿足備份需求，備份工具mysqldump是比較好的選擇；確保MySQL的log-bin選項是打開的，有了binlog，MySQL才能做完整的恢復、基于時間點的恢復、以及基于位置的恢復；備份二進制日志，用于故障時間點的恢復；在存儲資源許可的條件下，保留足夠多的備份集；定期從備份中進行恢復測試；需確保備份文件是有效的，是可以恢復的；通過恢復演練，測算恢復鎖需要的實際時間，以及所需要的資源，如CPU、磁盤空間、內存、網(wǎng)絡等。