MySQL企業備份案列

前言：上篇文檔分享了MySQL數據庫的幾種備份方法，以及各自的特點。下面我們通過一個企業級的備份案例了解一下MySQL數據庫的常見備份和恢復。（如果有看不懂的地方，可以參考小編主頁的上篇文檔：怎么對MySQL數據庫進行備份與恢復）

案例：

需求描述：某某公司的用戶信息數據庫為client，用戶資費數據表為user_info，該公司每周需要進行完全備份，每天需要進行增量備份。新增的用戶信息如下表所示：

一、一般恢復

1.添加數據庫、表、錄入信息

在進行備份前，先根據需求創建用戶信息數據庫client、用戶資費數據表user_info，并且根據需求描述中的表格插入前三條用戶的數據。 如下圖：

2.先進行一次完全備份

為了方便驗證二進制日志的增量恢復功能，我們在插入三條用戶數據后先對client數據庫的user_info數據表進行一次完全備份，然后在linux系統命令行下執行"mysqladmin -u root -p flush-logs"命令或在"mysql>"命令提示符下執行"flush logs；"生成新的二進制日志。如下圖：

3.繼續錄入新的數據并進行增量備份

繼續錄入兩個用戶的數據，并執行"mysqladmin -u root -p flush-logs"命令刷新二進制日志，進行增量備份。這樣，二進制日志文件mysql-bin.000003中僅保留插入兩個用戶數據的操作。如下圖：

4.模擬誤操作刪除user_info表

5.恢復操作

執行恢復操作時，需要先恢復完全備份，然后恢復增量備份。

二、基于位置恢復

1.由于上面已經做過恢復操作了，所以我們***步還是模擬誤操作刪除user_info表，然后恢復完全備份。操作同上，這里就略過了。

2.想要實現基于位置或時間點恢復數據，必須先通過查看二進制日志文件確定恢復的位置或時間點。使用"mysqlbinlog --no-defaults 二進制日志文件"可以查看日志文件的具體內容。如下圖：

通過查看日志文件的具體內容可以發現，在每進行一個操作之前都會有一個獨特的編號，如"# at 458"。此編號隨著操作數增多而變大，我們稱之為操作ID。在操作ID下面緊跟著的是時間標記，要實現基于位置或時間點恢復數據，需要分別依賴二進制日志文件中的操作ID或者時間標記。例如，通過二進制日志文件可以得知，在操作ID為"458"的時候，user_info表中插入了"王麻子"的用戶數據。因此執行以下命令可以實現僅恢復到操作ID為"458"之前的數據，即不恢復"王麻子"的信息。這時所恢復的數據是從二進制日志文件的開始位置直到指定位置。如下圖：

上述操作命令中，"--stop-position"指定的是停止的位置，如果僅恢復"王麻子"的信息，跳過"趙六"的信息，可以使用"--start-position"選項指定開始恢復數據的位置。這時所恢復的數據是從指定位置開始直到二進制日志文件的***。如下圖：

三、基于時間點恢復

基于時間點恢復數據所使用的選項是"--stop-datetime"，指定的時間同樣也是查詢二進制日志文件所得。

如下圖：執行以下操作可以實現恢復到"2:38:32"之前的數據，即不恢復"王麻子"的信息。

基于時間點恢復同樣也可以使用"--start-datetime"選項指定開始恢復數據的時間，命令格式與基于位置恢復的格式一樣，這里就不再給圖了。

四、制定企業備份策略的思路

在企業中備份策略并不是千篇一律的，而是根據每個企業的實際生產環境與業務需求指定合適的備份策略。無論是選擇完全備份，還是選擇增量備份，都需要考慮它們的優缺點，是否適合當前的環境。同時，為了保證恢復的完整性，建議開啟二進制日志功能，二進制日志文件給恢復工作也帶來了很大的靈活性，可以基于時間點或位置進行恢復。考慮到數據庫性能，我們可以將二進制日志文件保存到其他安全的硬盤中。

在進行熱備份時，備份操作和應用服務在同時運行，這樣就十分消耗系統資源了，導致數據庫服務性能下降，這就要求我們選擇合適的時間，如，在應用負擔很小的時候在進行備份操作。

需要注意的是，不是備份完就萬事大吉了，***確認備份是否可用，所以，備份之后的恢復測試是很有必要的，同時備份時間也要有靈活調整。如：

• 數據更新頻繁，則應該頻繁的備份
• 數據的重要性，在有適當更新時進行備份
• 在數據庫壓力小的時間段進行備份，如一周一次完全備份，每天進行增量備份。
• 中小公司，完全備份一般一天一次即可
• 大公司可每周進行一次完全備份，每天進行增量備份
• 盡量為企業實現主從復制架構，以增加數據的高可用性