MySQL中使用binlog時binlog格式的選擇

1、binlog的三種模式

1.statement level模式

每一條會修改數據的sql都會記錄到master的bin-log中。slave在複製的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。 優勢：statement level下的優勢，首先就是解決了row level下的缺點，不須要記錄每一行數據的變化，減小bin-log日誌量，節約io，提升性能。由於他只須要記錄在master上所執行的語句的細節，以及執行語句時候的上下文的信息。 缺點：因爲它是記錄的執行語句，因此爲了讓這些語句在slave端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證全部語句在slave端被執行的時候可以獲得和在master端執行時候相同的結果。另外就是,因爲mysql如今發展比較快，不少的新功能加入，使mysql的複製遇到了不小的挑戰,天然複製的時候涉及到越複雜的內容，bug也就越容易出現。在statement level下，目前已經發現的就有很多狀況會形成mysql的複製問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，好比sleep()在有些版本就不能正確複製。

2.rowlevel模式

日誌中會記錄成每一行數據被修改的形式，而後在slave端再對相同的數據進行修改 優勢：bin-log中能夠不記錄執行的sql語句的上下文相關的信息，僅僅只須要記錄那一條記錄被修改了，修改爲什麼樣了。因此row level的日誌的內容會很是清楚的記錄下每一行數據修改的細節。並且不會出現某些特定狀況下的存儲過程，或function,以及trigger的調用和觸發沒法被正確複製的問題。 缺點：row level下，全部的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改記錄，這樣可能會產生大量的日誌內容，好比有這樣一條update語句：update product set owner_member_id='d' where owner_member_id='a',執行以後，日誌中記錄的不是這條update語句所對應的事件(mysql是以事件的形式來記錄bin-log日誌)，而是這條語句所更新的每一條記錄的變化狀況，這樣就記錄成不少條記錄被更新的不少事件。天然，bin-log日誌的量會很大。

3.mixed模式

實際上就是前兩種模式的結合，在mixed模式下，mysql會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在statement和row之間選一種。新版本中的statement level仍是和之前同樣，僅僅記錄執行的語句。而新版本的mysql中對row level模式被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄，若是sql語句確實就是update或者delete 等修改數據的語句，那麼仍是會記錄全部行的變動。

2、咱們使用binlog時應該選擇什麼格式呢

經過上面的介紹咱們知道了binlog_format爲STATEMENT在一些場景下可以節省IO、加快同步速度，可是對於InnoDB這種事務引擎，在READ-COMMITTED、READ-UNCOMMITTED隔離級別或者參數innodb_locks_unsafe_for_binlog爲ON時，禁止binlog_format=statement下的寫入，同時對於binlog_format=mixed這種對於非事務引擎、其餘隔離級別默認寫statement格式的模式也只會記錄row格式。

> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+

> create table t(c1 int) engine=innodb;

> set binlog_format=statement;

> insert into t values(1);
ERROR 1665 (HY000): Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

> set binlog_format='mixed';

> show binlog events in 'mysql-bin.000004'\G
*************************** 3. row ***************************
   Log_name: mysql-bin.000002
        Pos: 287
 Event_type: Gtid
  Server_id: 3258621899
End_log_pos: 335
       Info: SET @@SESSION.GTID_NEXT= 'ed0eab2f-dfb0-11e7-8ad8-a0d3c1f20ae4:9375'
*************************** 4. row ***************************
   Log_name: mysql-bin.000002
        Pos: 335
 Event_type: Query
  Server_id: 3258621899
End_log_pos: 407
       Info: BEGIN
*************************** 5. row ***************************
   Log_name: mysql-bin.000002
        Pos: 407
 Event_type: Table_map
  Server_id: 3258621899
End_log_pos: 452
       Info: table_id: 124 (test.t)
*************************** 6. row ***************************
   Log_name: mysql-bin.000002
        Pos: 452
 Event_type: Write_rows_v1
  Server_id: 3258621899
End_log_pos: 498
       Info: table_id: 124 flags: STMT_END_F
*************************** 7. row ***************************
   Log_name: mysql-bin.000002
        Pos: 498
 Event_type: Xid
  Server_id: 3258621899
End_log_pos: 529
       Info: COMMIT /* xid=18422 */
複製代碼

爲何READ-COMMITTED(RC)、READ-UNCOMMITTED下沒法使用statement格式binlog？這是由於語句在事務中執行時，可以看到其餘事務提交或者正在寫入的數據。事務提交後binlog寫入，而後在從庫回放，就會看到的數據會與主庫寫入時候不對應。 例如： 有表：

+------+------+
| a    | b    |
+------+------+
|   10 |    2 |
|   20 |    1 |
+------+------+
複製代碼

咱們作以下操做：

1. session1在事務中作update，UPDATE t1 SET a=11 where b=2;知足條件的有行(10,2)的一條記錄，並未提交。
2. session2也作update操做，將行(20,1)更新爲(20,2)並提交。
3. 而後前面的sesssion1提交對行(10,2)的更新。

若是binlog中使用Statement格式記錄，在slave回放的時候，session2中的更新因爲先提交會先回放，將行(20,1)更新爲（20,2)。隨後回放session1的語句UPDATE t1 SET a=11 where b=2;語句就會將更新(10,2)和(20,2)兩行爲(11,2)。這就致使主庫行爲(11, 2), (20,2)，slave端爲(11,2), (11, 2)。

3、問題分析

上面是經過一個具體的例子說明。本質緣由是RC事務隔離級別並不知足事務串行化執行要求，沒有解決不可重複和幻象讀。

對於Repetable-Read和Serializable隔離級別就不要緊，Statement格式記錄。這是由於對於RR和Serializable，會保證可重複讀，在執行更新時候除了鎖定對應行還會在可能插入知足條件行的時候加GAP Lock。上述case更新時，session1更新b =2的行時，會把全部行和範圍都鎖住，這樣session2在更新的時候就須要等待。從隔離級別的角度看Serializable知足事務的串行化，所以binlog串行記錄事務statement格式是能夠的。同時InnoDB的RR隔離級別實際已經解決了不可重複讀和幻象讀，知足了ANSI SQL標準的事務隔離性要求。

READ-COMMITTED、READ-UNCOMMITTED的binlog_format限制能夠說對於全部事務引擎都適用。

4、拓展內容

對於InnoDB RR和Serializable隔離級別下就必定能保證binlog記錄Statement格式麼？也不必定。在Innodb中存在參數innodb_locks_unsafe_for_binlog控制GAP Lock，該參數默認爲OFF：

mysql> show variables like 'innodb_locks_unsafe_for_binlog';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_locks_unsafe_for_binlog | OFF   |
+--------------------------------+-------+
1 row in set (0.01 sec)
複製代碼

即RR級別及以上除了行鎖還會加GAP Lock。但若是該參數設置爲ON，對於當前讀就不會加GAP Lock，即在RR隔離級別下須要加Next-key lock的當前讀蛻化爲READ-COMMITTED。因此若是此參數設置爲ON時即使使用的事務隔離級別爲Repetable-Read也不能保證從庫數據的正確性。

5、總結

對於線上業務，若是使用InnoDB等事務引擎，除非保證RR及以上隔離級別的寫入，必定不要設置爲binlog_format爲STATEMENT，不然業務就沒法寫入了。而對於binlog_format爲Mixed模式，RR隔離級別如下這些事務引擎也必定寫入的是ROW event。