MySQL Binlog日誌

Thresh

Binlog 記錄模式

Redo Log 是屬於InnoDB引擎所特有的日誌，而MySQL Server也有本身的日誌，即 Binary log（二進制日誌），簡稱Binlog。

Binlog是記錄全部數據庫表結構變動以及表數據修改的二進制日誌，不會記錄SELECT和SHOW這類操做。

Binlog日誌是以事件形式記錄，還包含語句所執行的消耗時間。

開啓Binlog日誌有如下兩個最重要的使用場景。

主從複製：在主庫中開啓Binlog功能，這樣主庫就能夠把Binlog傳遞給從庫，從庫拿到Binlog後實現數據恢復達到主從數據一致性。
數據恢復：經過mysqlbinlog工具來恢復數據。

Binlog文件名默認爲「主機名_binlog-序列號」格式，例如oak_binlog-000001，也能夠在配置文件中指定名稱。

文件記錄模式有STATEMENT、ROW和MIXED三種，具體含義以下。

• ROW（row-based replication, RBR）

日誌中會記錄每一行數據被修改的狀況，而後在slave端對相同的數據進行修改。

優勢：能清楚記錄每個行數據的修改細節，能徹底實現主從數據同步和數據的恢復。
缺點：批量操做，會產生大量的日誌，尤爲是alter table會讓日誌暴漲。

• STATMENT（statement-based replication, SBR）

每一條被修改數據的SQL都會記錄到master的Binlog中，slave在複製的時候SQL進程會解析成和原來master端執行過的相同的SQL再次執行。簡稱SQL語句複製。

優勢：日誌量小，減小磁盤IO，提高存儲和恢復速度
缺點：在某些狀況下會致使主從數據不一致，好比last_insert_id()、now()等函數。

• MIXED（mixed-based replication, MBR）

以上兩種模式的混合使用，通常會使用 STATEMENT 模式保存binlog，對於STATEMENT模式沒法複製的操做使用 ROW 模式保存binlog，MySQL會根據執行的SQL語句選擇寫入模式。

Binlog 寫入機制

經常使用的log event有：Query event、Row event、Xid event等。binlog文件的內容就是各類Log event的集合。

• 根據記錄模式和操做觸發event事件生成log event（事件觸發執行機制）
• 將事務執行過程當中產生log event寫入緩衝區，每一個事務線程都有一個緩衝區

Log Event保存在一個binlog_cache_mngr數據結構中，在該結構中有兩個緩衝區，一個是stmt_cache，用於存放不支持事務的信息；另外一個是trx_cache，用於存放支持事務的信息。

• 事務在提交階段會將產生的log event寫入到外部binlog文件中。

不一樣事務以串行方式將log event寫入binlog文件中，因此一個事務包含的log event信息在binlog文件中是連續的，中間不會插入其餘事務的log event。

Binlog 文件操做

Binlog狀態查看

show variables like 'log_bin';

開啓Binlog功能
須要修改my.cnf或my.ini配置文件，在[mysqld]下面增長log_bin=mysql_bin_log，重啓MySQL服務。

#log-bin=ON 
#log-bin-basename=mysqlbinlog 
binlog-format=ROW 
log-bin=mysqlbinlog

執行開啓語句

set global log_bin=mysqllogbin;

使用show binlog events命令

show binary logs; //等價於show master logs; 
show master status; 
show binlog events; 
show binlog events in 'mysqlbinlog.000001'\G;
結果:
     Log_name: mysql_bin.000001   //此條log存在那個文件中
        Pos: 174                 //log在bin-log中的開始位置 
     Event_type: Intvar          //log的類型信息 
        Server_id: 1  //能夠查看配置中的server_id,表示log是那個服務器產生 
     End_log_pos: 202          //log在bin-log中的結束位置 
        Info: INSERT_ID=2    //log的一些備註信息，能夠直觀的看出進行了什麼操做

能夠用mysql自帶的工具mysqlbinlog

mysqlbinlog "文件名" mysqlbinlog "文件名" > "文件名好比:test.sql"

使用 binlog 恢復數據

//按指定時間恢復 
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop-datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234 
//按事件位置號恢復 
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234

mysqldump：按期所有備份數據庫數據。mysqlbinlog: 能夠作增量備份和恢復操做。

刪除Binlog文件

purge binary logs to 'mysqlbinlog.000001'; //刪除指定文件 
purge binary logs before '2020-04-28 00:00:00'; //刪除指定時間以前的文件 
reset master; //清除全部文件

能夠經過設置expire_logs_days參數來啓動自動清理功能。默認值爲0表示沒啓用。設置爲1表示超出1天binlog文件會自動刪除掉

Redo Log和 Binlog 區別

• Redo Log是屬於InnoDB引擎功能，Binlog是屬於MySQL Server自帶功能，而且是以二進制文件記錄。
• Redo Log屬於物理日誌，記錄該數據頁更新狀態內容，Binlog是邏輯日誌，記錄更新過程。
• Redo Log日誌是循環寫，日誌空間大小是固定，Binlog是追加寫入，寫完一個寫下一個，不會覆蓋使用。
• Redo Log做爲服務器異常宕機後事務數據自動恢復使用，Binlog能夠做爲主從複製和數據恢復使用。Binlog沒有自動crash-safe能力。

(crash-safe 即在 InnoDB 存儲引擎中，事務提交過程當中任何階段，MySQL忽然奔潰，重啓後都能保證事務的完整性，已提交的數據不會丟失，未提交完整的數據會自動進行回滾。這個能力依賴的就是redo log和unod log兩個日誌。)