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的模式

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

postgresql 的三種日誌

mysql binlog日誌刪除

壓縮mysql binlog日誌

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

postgresql 的三種日誌

mysql binlog日誌刪除

壓縮mysql binlog日誌

相關推薦