mysqk備份恢復
MYSQL備份恢復
MySQL備份一般采取全庫備份加日誌備份的方式.
1、binlog
mysql的二進制日誌記錄著該數據庫的所有增刪改的操作日誌, 可以使用mysqlbinlog命令來查看。
默認關閉的 在/etc/my.conf 開啟 重啟
指定路徑
Binlog的用途 主從同步 恢復數據庫
查看產生的binary log 註：查看binlog內容是為了恢復數據
bin-log因為是二進制文件，不能通過文件內容查看命令直接打開查看，mysql提供兩種方式查看方式，我們先對數據庫進行一下增刪改的操作，否則
重啟開始一個新日誌
查看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 （--verbose）選項，想看到更詳細的信息可以將該選項給兩次如-vv
先切換到binlog所在的目錄下
查看mysqlbinlog 000001目錄
mysqlbinlog和可以通過--read-from-remote-server選項從遠程服務器讀取二進制日誌文件，這時需要一些而外的連接參數，如-h，-P，-p，-u等，這些參數僅在指定了--read-from-remote-server後有效。
無論是行模式、語句模式還是混合模式的二進制日誌文件，被mysqlbinlog工具解析後都可直接應用與MySQL Server進行基於時間點、位置或數據庫的恢復。
可以看出delete事件發生position是287，事件結束position是416
恢復流程：直接用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 事件 可以看到刪除日誌
數據恢復刪除之前
數據恢復刪除之後
查看最終恢復結果
本文出自 “chaixinwang” 博客，請務必保留此出處http://chaixinwang.blog.51cto.com/13052229/1945410
mysqk備份恢復