mysql rc模式时binlog_format=row的解释【转】

总体来说：在 tx_isolation= READ-COMMITTED 、binlog_format =statement 的情况下，mysql 没有gap 锁，这样binlog 记录的数据修改的顺序可能会导致 复制环境的 slave 数据和master 数据不一致。

模拟步骤

数据初始化

 CREATE TABLE `gapt` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `ind_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
mysql> select * from gapt; +----+------+ | id | name | +----+------+ | 1 | 1 | | 10 | 10 | | 11 | 11 | | 15 | 15 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 8 | 8 | | 9 | 9 | +----+------+ 

session1 和 session2 模拟

@session 1:
mysql> show variables like '%tx_isolation%'; +---------------+----------------+ | Variable_name | Value | +---------------+----------------+ | tx_isolation | READ-COMMITTED | +---------------+----------------+ 1 row in set (0.00 sec) mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update gapt set id=name+20 where name between 5 and 11; Query OK, 6 rows affected (0.00 sec) Rows matched: 6 Changed: 6 Warnings: 0 @session2 mysql> show variables like '%tx_isolation%'; +---------------+----------------+ | Variable_name | Value | +---------------+----------------+ | tx_isolation | READ-COMMITTED | +---------------+----------------+ 1 row in set (0.00 sec) mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into gapt select 24,5; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> system date Fri Jun 19 10:55:38 CST 2015 @session1 mysql> select * from gapt where name between 5 and 11; +----+------+ | id | name | +----+------+ | 30 | 10 | | 31 | 11 | | 24 | 5 | | 25 | 5 | | 26 | 6 | | 28 | 8 | | 29 | 9 | +----+------+ 7 rows in set (0.00 sec) #你会发现 6行变成7行了， mysql> system date; Fri Jun 19 10:55:50 CST 2015 mysql> commit; Query OK, 0 rows affected (0.00 sec) 

重点： 两个 session 执行完 commit，并且按照 binlog_format = statement 日志模式的话，那么最终的binlog日志记录应该是按照事务 commit 的顺序记录的。

#binlog 实际存储的执行顺序
@session2 
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> insert into gapt select 24,5; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> commit; Query OK, 0 rows affected (0.00 sec) #session1 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update gapt set id=name+20 where name between 5 and 11; Query OK, 6 rows affected (0.00 sec) mysql> commit; 

如果是这样记录的话你会发现这个 @session1 的 update 语句会把 session2 刚刚插入的 name='5',id=24 数据也会更新掉了！！这也就导致了（如果有复制）从库从库的数据就会和复制的主库不一样了！！

问题来了，我是如何模拟的呢？我是设置 tx_isolation=READ-COMMITTED binlog_format= MIXED 的时候，上面的操作可以正确执行，这是因为 MySQL 识别到了这个可能存在不一致的复制情况，就把上面的操作转换成了 binlog_format=row 的二进制日志。

#150619 10:55:00 server id 4306 end_log_pos 283 Table_map: `repl`.`gapt` mapped to number 52 #150619 10:55:00 server id 4306 end_log_pos 319 Write_rows: table id 52 flags: STMT_END_F BINLOG ' hISDVRPSEAAALgAAABsBAAAAADQAAAAAAAEABHJlcGwABGdhcHQAAgMPAmAAAg== hISDVRfSEAAAJAAAAD8BAAAAADQAAAAAAAEAAv/8GAAAAAE1 '/*!*/; # at 319 #150619 10:55:09 server id 4306 end_log_pos 346 Xid = 447 #session2 的 commit COMMIT/*!*/; # at 346 #150619 10:57:04 server id 4306 end_log_pos 414 Query thread_id=16 exec_time=0 error_code=0 SET TIMESTAMP=1434682624/*!*/; BEGIN /*!*/; # at 414 # at 460 #150619 10:54:14 server id 4306 end_log_pos 460 Table_map: `repl`.`gapt` mapped to number 52 #150619 10:54:14 server id 4306 end_log_pos 578 Update_rows: table id 52 flags: STMT_END_F BINLOG ' VoSDVRPSEAAALgAAAMwBAAAAADQAAAAAAAEABHJlcGwABGdhcHQAAgMPAmAAAg== VoSDVRjSEAAAdgAAAEICAAAAADQAAAAAAAEAAv///AUAAAABNfwZAAAAATX8BgAAAAE2/BoAAAAB NvwIAAAAATj8HAAAAAE4/AkAAAABOfwdAAAAATn8CgAAAAIxMPweAAAAAjEw/AsAAAACMTH8HwAA AAIxMQ== '/*!*/; # at 578 #150619 10:57:04 server id 4306 end_log_pos 605 Xid = 443 #session1 的 commit COMMIT/*!*/; 

binlog_format 为什么转化为 row 就可以呢，因为 row 格式的日志记录的是底层数据真正的变化，这样就不会导致复制环境的主从数据不一致了。

ps: 如果有什么理解错误的，或者模拟的不合理的地方，麻烦纠正指出来，谢谢。