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

在認識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的模式

一、 若是生產中使用MySQL的特殊功能相對少（存儲過程、觸發器、函數）。選擇默認的語句模式，Statement Level。

二、 若是生產中使用MySQL的特殊功能較多的，能夠選擇Mixed模式。

三、 若是生產中使用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';

原文：https://mp.weixin.qq.com/s/Yh0ZGmBwCxA4u3qPssmmSw