ble 文件 eve 圖解 nag 一行 人的 三種模式 jpg

在講解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日誌三種模式選擇及配置