MySQL binlog日誌三種模式選擇及配置

標籤：show   批量修改   code   之間   模式   row   image   for   state   

在認識binlog日誌三種模式前，先瞭解一下解析binlog日誌的命令工mysqlbinlog。mysqlbinlog工具的作用是解析mysql的二進位binlog日誌內容，把二進位日誌解析成可以在MySQL資料庫裡執行的SQL語句。binlog日誌未經處理資料是以二進位形式存在的，需要使用mysqlbinlog工具轉換成SQL語句形式。

mysql的binlog日誌作用是用來記錄mysql內部增刪改等對mysql資料庫有更新內容的記錄（對資料庫進行改動的操作），對資料庫查詢的語句如show，select開頭的語句，不會被binlog日誌記錄，主要用於資料庫的主從複製與及增量恢複。

案例：

在對資料庫進行定時備份時，只能備份到某個時間點，假如在淩晨0點進行全備了，但是在中午12點出現故障需要恢複資料，使用0點的全備只能恢複到0點時刻的資料，難道0點到12點的資料只能丟失了嗎？

這時就是體現binlog日誌重要性的時候了，需要對binlog日誌進行定時推送（一分鐘一次或五分鐘一次，時間頻率視業務情境而定）完成增量備份。當出現故障時，可以使用定時備份和增量備份恢複到故障點時刻的資料。具體的恢複方案，這裡不做簡述，後面再寫文章來講解。

binlog日誌三種模式

ROW Level

記錄的方式是行，即如果批量修改資料，記錄的不是批量修改的SQL語句事件，而是每條記錄被更改的SQL語句，因此，ROW模式的binlog記錄檔會變得很“重”。

優點：row level的binlog日誌內容會非常清楚的記錄下每一行資料被修改的細節。而且不會出現某些特定情況下預存程序或function，以及trigger的調用和觸發器無法被正確複製的問題。

缺點：row level下，所有執行的語句當記錄到日誌中的時候，都以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容，產生的binlog日誌量是驚人的。批量修改幾百萬條資料，那麼記錄幾百萬行……

Statement level(預設)

記錄每一條修改資料的SQL語句（批量修改時，記錄的不是單條SQL語句，而是批量修改的SQL語句事件）。看上面的圖解可以很好的理解row level和statement level兩種模式的區別。

優點：statement模式記錄的更改的SQ語句事件，並非每條更改記錄，所以大大減少了binlog日誌量，節約磁碟IO，提高效能。

缺點：statement level下對一些特殊功能的複製效果不是很好，比如：函數、預存程序的複製。由於row level是基於每一行的變化來記錄的，所以不會出現類似問題

Mixed

實際上就是前兩種模式的結合。在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。

企業情境如何選擇binlog的模式

1、 如果生產中使用MySQL的特殊功能相對少（預存程序、觸發器、函數）。選擇預設的語句模式，Statement Level。

2、 如果生產中使用MySQL的特殊功能較多的，可以選擇Mixed模式。

3、 如果生產中使用MySQL的特殊功能較多，又希望資料最大化一致，此時最好Row level模式；但是要注意，該模式的binlog非常“沉重”。

查看binlog模式

mysql> show global variables like "%binlog_format%";  +---------------+-----------+  | Variable_name | Value    |  +---------------+-----------+  | binlog_format | STATEMENT |  +---------------+-----------+ 

配置binlog記錄模式

vim my.cnf（在[mysqld]模組中配置）

log-bin = /data/3306/mysql-bin  binlog_format="STATEMENT"  #binlog_format="ROW"  #binlog_format="MIXED" 

不重啟，使配置在msyql中生效

SET global binlog_format=‘STATEMENT‘;

MySQL binlog日誌三種模式選擇及配置