第一:Mysql Binlog有三種模式
binlog有三種格式：Statement、Row以及Mixed。
–基於SQL語句的複製(statement-based replication,SBR)，
–基於行的複製(row-based replication,RBR)，
–混合模式複製(mixed-based replication,MBR)。
1 Statement ,簡單的說能記錄每條操作sql
每一條會修改數據的sql都會記錄在binlog中。
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高性能。
缺點：由於記錄的只是執行語句，爲了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關信息，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有很多相關問題。
ps：相比row能節約多少性能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO性能問題。
2 Row
5.1.5版本的MySQL纔開始支持row level的複製,它不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確複製的問題.
缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。***
這個模式數據恢復時還原sql無法執行!!!
ps:新版本的MySQL中對row level模式也被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果sql語句確實就是update或者delete等修改數據的語句，那麼還是會記錄所有行的變更。
3 Mixed
從5.1.8版本開始，MySQL提供了Mixed格式，實際上就是Statement與Row的結合。
在Mixed模式下，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從複製的操作，則採用row格式保存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。
總結:配置時最好用mixed
第二 相關配置
binlog_format=mixed //日誌模式,最好調成mixed,row 模式用mysqlbinlog 還原的sql是無法直接執行恢復的!!
datadir = /www/server/data //數據存儲文件,包括bin-log
log-bin=mysql-bin //開啓log-bin 名稱叫mysql-bin 位置在上面配置
第三恢復操作
1:根據配置文件找到bin-log 位置,根據時間判斷需要恢復的log
2:用 mysqlbinlog 工具將bin-log 還原成sql
ps:
1:查找bin-log 跟mysqlbinlog 可以用 find /(文件夾) -name mysqlbinlog
2:查看數據庫bin-log 相關 mysql> show variables like ‘log_%’;
下面是使用mysqlbinlog工具相關
eg1: /www/server/mysql/bin/mysqlbinlog --skip-gtids=true mysql-binl.000006 > sss1.sql //直接將整個binlog 轉成sql,這僅限於bin-log 模式是Statement 時,row 模式會被加密成base64,–skip-gtids=true 這是去除數據庫gtids,不然同一個數據庫數據無法恢復,gtids只能執行一次所以要去除
eg2:/www/server/mysql/bin/mysqlbinlog -v --base64-output=decode-rows mysql-bin.000013 > sss1.sql //這個適用於row模式或者mixed 模式,會將bin-log 解析成下面類似的sql,這對還原數據沒什麼卵用,所以還是要把bin-log模式 設置成mixed
BEGIN
/*!*/;
# at 192
#200605 16:44:59 server id 1 end_log_pos 251 CRC32 0x3ae104fe Table_map: `jfqp`.`jz_nav_cat` mapped to number 70
# at 251
#200605 16:44:59 server id 1 end_log_pos 323 CRC32 0xbbadc0d9 Write_rows: table id 70 flags: STMT_END_F
### INSERT INTO `jfqp`.`jz_nav_cat`
### SET
### @1=4
### @2='測試導航'
### @3=1
### @4='測試測試'
# at 323
#200605 16:44:59 server id 1 end_log_pos 396 CRC32 0x0daea76d Query thread_id=31 exec_time=0 error_code=0
SET TIMESTAMP=1591346699/*!*/;
COMMIT
eg: 下面是比較完整,根據時間跟數據庫恢復
/www/server/mysql/bin/mysqlbinlog -v --base64-output=decode-rows --skip-gtids=true mysql-bin.000013 --database=test_db --start-datetime=‘2016-07-20 00:00:01’ --stop-datetime=‘2016-07-24 23:59:59’ > sss1.sql
總結:Bin-log模式最好用mixed