MySQL Binlog Mixed模式记录成Row格式
2017-05-18 13:56
387 查看
概念:
binlog format有三种形式:Statement、Mixed、Row,具体的信息可以自行到网上搜查。
分析(本文碰到的案例):
查看MySQL binlog format
测试语句:
Binlog 记录图:
问题来了,我想要出来的binlog format是Statement,而不是Row。而一条insert into tb select * from ta的简单语句在Mixed模式下记录了Row模式的binlog。原因是什么?
首先确实在一些特定的情况下,Mixed会被转换成Row模式:
上面来自网络,有兴趣的可以自己测试测试。而对于本文中的sql,符合不了上面的条件,但binlog也记录成了Row格式。所以还是很奇怪为什么binlog格式被转换了,日常工作的时候有遇到过执行一条sql,会报一个warning:
难道因为这个导致转换的?因为上面的SQL可以重现,没有报warning,所以这个情况排除。根据经验想到了一个参数:innodb_locks_unsafe_for_binlog,看到里面讲到事务隔离级别,那就看看隔离级别的情况:
看到隔离级别是提交读,即不可重复读。把事务隔离级别设置成默认的 REPEATABLE READ:
再执行测试里的SQL,发现这时候Mixed的binlog记录了Statement格式,正常了,符合预期了。难道就是这个事务隔离级别的问题引起的?在手册里发现了这句:
展开可以看例子:
View
Code
经过测试,在5.1、5.5、5.6都有这个情况,可能这个本身就不是问题。:)
binlog format有三种形式:Statement、Mixed、Row,具体的信息可以自行到网上搜查。
分析(本文碰到的案例):
查看MySQL binlog format
dba@192.168.111.4 : dba_test 02:33:39>show variables like 'binlog_format%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | MIXED | +---------------+-------+
测试语句:
dba@192.168.111.4 : dba_test 02:24:14>create table tmp_test(id int,name varchar(64),age int,primary key(id)) engine = innodb; Query OK, 0 rows affected (0.05 sec) dba@192.168.111.4 : dba_test 02:24:23>insert into tmp_test values(1,'aaa',11); Query OK, 1 row affected (0.02 sec) dba@192.168.111.4 : dba_test 02:25:17>insert into tmp_test values(2,'bbb',22); Query OK, 1 row affected (0.02 sec) dba@192.168.111.4 : dba_test 02:25:23>insert into tmp_test values(3,'ccc',33); Query OK, 1 row affected (0.01 sec) dba@192.168.111.4 : dba_test 02:25:28>insert into tmp_test values(4,'ddd',44); Query OK, 1 row affected (0.01 sec) dba@192.168.111.4 : dba_test 02:25:34>insert into tmp_test values(5,'eee',55); Query OK, 1 row affected (0.01 sec) dba@192.168.111.4 : dba_test 02:25:42>select * from tmp_test; +----+------+------+ | id | name | age | +----+------+------+ | 1 | aaa | 11 | | 2 | bbb | 22 | | 3[/b] | ccc | 33 | | 4 | ddd | 44 | | 5 | eee | 55 | +----+------+------+ 5 rows in set (0.01 sec) dba@192.168.111.4 : dba_test 02:25:50>create table tmp_test_bak(id int,name varchar(64),age int,primary key(id)) engine = innodb; Query OK, 0 rows affected (0.03 sec) dba@192.168.111.4 : dba_test 02:26:31>insert into tmp_test_bak select * from tmp_test; ###记录成了Row模式 Query OK, 5 rows affected (0.03 sec) Records: 5 Duplicates: 0 Warnings: 0
Binlog 记录图:
问题来了,我想要出来的binlog format是Statement,而不是Row。而一条insert into tb select * from ta的简单语句在Mixed模式下记录了Row模式的binlog。原因是什么?
首先确实在一些特定的情况下,Mixed会被转换成Row模式:
. 当 DML 语句更新一个 NDB 表时; . 当函数中包含 UUID() 时; . 2 个及以上包含 AUTO_INCREMENT 字段的表被更新时; . 执行 INSERT DELAYED 语句时; . 用 UDF 时; . 视图中必须要求运用 row 时,例如建立视图时使用了 UUID() 函数;
上面来自网络,有兴趣的可以自己测试测试。而对于本文中的sql,符合不了上面的条件,但binlog也记录成了Row格式。所以还是很奇怪为什么binlog格式被转换了,日常工作的时候有遇到过执行一条sql,会报一个warning:
Warning: Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT
难道因为这个导致转换的?因为上面的SQL可以重现,没有报warning,所以这个情况排除。根据经验想到了一个参数:innodb_locks_unsafe_for_binlog,看到里面讲到事务隔离级别,那就看看隔离级别的情况:
dba@192.168.111.4 : dba_test 05:46:56>select @@global.tx_isolation; +-----------------------+ | @@global.tx_isolation | +-----------------------+ | READ-COMMITTED | +-----------------------+ 1 row in set (0.01 sec) dba@192.168.111.4 : dba_test 06:36:45>select @@session.tx_isolation; +------------------------+ | @@session.tx_isolation | +------------------------+ | READ-COMMITTED | +------------------------+ 1 row in set (0.01 sec)
看到隔离级别是提交读,即不可重复读。把事务隔离级别设置成默认的 REPEATABLE READ:
dba@192.168.111.4 : dba_test 06:41:02>set session transaction isolation level REPEATABLE READ; Query OK, 0 rows affected (0.14 sec) dba@192.168.111.4 : dba_test 06:41:42>select @@session.tx_isolation; +------------------------+ | @@session.tx_isolation | +------------------------+ | REPEATABLE-READ | +------------------------+ 1 row in set (0.00 sec)
再执行测试里的SQL,发现这时候Mixed的binlog记录了Statement格式,正常了,符合预期了。难道就是这个事务隔离级别的问题引起的?在手册里发现了这句:
Note In MySQL 5.7, when READ COMMITTED isolation level is used, or the deprecated innodb_locks_unsafe_for_binlog system variable is enabled,
there is no InnoDB gap locking except for foreign-key constraint checking and duplicate-key checking. Also, record locks for nonmatching
rows are released after MySQL has evaluated the WHERE condition. If you use READ COMMITTED or enable innodb_locks_unsafe_for_binlog, you must use row-based binary logging.
展开可以看例子:
View
Code
经过测试,在5.1、5.5、5.6都有这个情况,可能这个本身就不是问题。:)
相关文章推荐
- MySQL Binlog Mixed模式记录成Row格式
- MySQL 中二进制日志 (binlog) 3 种不同的格式(Mixed,Statement,Row)
- mysql主服务器 binlog_format 的 statement,row, mixed 三种格式对比。
- MySQL Binlog Mixed模式记录成Row格式
- Mysql 主从复制-Binlog详细解析(Row格式)
- 用mysqlbinlog查看row格式的事件
- mysql row binlog内容记录
- [MySQL binlog]mysql如何彻底解析Mixed日志格式的binlog
- ROW 格式binlog 在MySQL5.6上的数据恢复实验
- mysqlbinlog 查看执行的sql (row模式)
- MySQL在ROW模式下通过binlog提取SQL语句
- mysql binlog row格式查看
- mysqlbinlog 查看具体的sql语句 (binlog_format=row模式)
- binlog三种模式的区别(row,statement,mixed)
- mysql binlog row格式查看
- mysql 在row模式下truncate 与 delete 二进制日志记录的差异
- 用mysqlbinlog查看row格式的事件
- binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)
- 【20180507】MySQL主从在线修改binlog格式从STATEMENT更改成ROW格式
- MySQL binlog_format (Mixed,Statement,Row)[转]