mysql備份恢復
MYSQL備份恢復
MySQL備份一般採取全庫備份加日誌備份的方式.
1、binlog
mysql的二進位制日誌記錄著該資料庫的所有增刪改的操作日誌, 可以使用mysqlbinlog命令來檢視。
預設關閉的 在/etc/my.conf 開啟 重啟
指定路徑
Binlog的用途 主從同步恢復資料庫
檢視產生的binary log注：檢視binlog內容是為了恢復資料
bin-log因為是二進位制檔案，不能通過檔案內容檢視命令直接開啟檢視，mysql提供兩種方式檢視方式，我們先對資料庫進行一下增刪改的操作，否則log裡邊資料有點空。
重啟開始一個新日誌
檢視MySQL Server上的二進位制日誌
檢視二進位制日誌資訊的命令：
語法格式：SHOW BINLOG EVENTS[IN'log_name'] [FROM pos] [LIMIT [offset,] row_count]
檢視指定二進位制日誌事件
SLAVE複製執行緒。
檢視到檔案中具體的內容並應於恢復場景還得藉助mysqlbinlog這個工具。
語法格式：mysqlbinlog [options] log_file ...
mysqlbinlog的可用選項可參考man手冊。
二進位制日誌檔案的格式包含行模式、語句模式和混合模式，基於語句的日誌中事件資訊包含執行的語句等，基於行的日誌中事件資訊包含的是行的變化資訊等。
2 方便查詢SQL語句使用mysqlbinlog工具 -v
先切換到binlog所在的目錄下
檢視mysqlbinlog 000001目錄
mysqlbinlog和可以通過--read-from-remote-server選項從遠端伺服器讀取二進位制日誌檔案，這時需要一些而外的連線引數，如-h，-P，-p，-u等，這些引數僅在指定了--read-from-remote-server後有效。
無論是行模式、語句模式還是混合模式的二進位制日誌檔案，被mysqlbinlog工具解析後都可直接應用與MySQL Server進行基於時間點、位置或資料庫的恢復。
可以看出delete事件發生position是287
恢復流程：直接用bin-log日誌將資料庫恢復到刪除位置287前,然後跳過故障點,再進行恢復
由於之前沒有做過全庫備份，所以要使用所有binlog日誌恢復，所以生產環境中需要很長時間恢復，匯出相關binlog檔案
刪除test資料庫
利用binlog恢復資料
恢復成功
--start-datetime
從二進位制日誌中讀取指定時間戳或者本地計算機時間之後的日誌事件。
--stop-datetime
從二進位制日誌中讀取指定時間戳或者本地計算機時間之前的日誌事件。
--start-position
從二進位制日誌中讀取指定position事件位置作為開始。
--stop-position
從二進位制日誌中讀取指定position事件位置作為事件截至。
mysqldump介紹
mysqldump一般在資料量很小的時候（幾個G）可以用於備份。當資料量比較大的情況下，就不建議用mysqldump工具進行備份了。
2）mysqldump可以針對單個表、多個表、單個數據庫、多個數據庫、所有資料庫進行匯出的操作
#mysqldump [options] db_name [tbl_name ...]//匯出指定資料庫或單個表
#mysqldump [options] --databases db_name... //匯出多個數據庫
#mysqldump [options] --all-databases//匯出所有
匯出資料庫test
完整備份 重新開啟新binlog
資料庫匯入
實現mysqldum全庫備份和binlog資料恢復
檢查開啟binlog 建立原始資料
方案：mysqldump全庫備份+binlog還原
1、mysqldump備份方案：
每週一凌晨1點全庫備份
2、備份步驟
模擬一個完整全庫備份
備份mysqldump全庫備份之前的binlog日誌檔案
模擬失誤刪除資料
建立tom3
剛才刪除的資料（id=2）恢復回來了，但備份後產生的資料卻丟失了所以還得利用binlog進一步還原因為刪除是在全庫備份後發生的，而mysqldump全庫備份時使用--flush-logs選項，所以只需要分析全庫備份後的binlog即mysql-bin.000002。
檢視 log_bin 事件 可以看到刪除日誌
資料恢復刪除之前
資料恢復刪除之後
檢視最終恢復結果
轉載於:https://blog.51cto.com/chaixinwang/1945410