【MySQL】 binlog_direct_non_transactional_updates 参数的用法:
这个参数是5.1.44 才引入的,从命名可理解为--非事务直接写binlog 。可怎么觉得不对劲呢,我们知道对于非事务表(如:MyISAM),即使发起了事务begin,而结果不管提交commit,还是回滚rollback;对中间执行了的非事务表的写操作都会记录binlog。
我们看一遍演示:
1.2 解析主库binlog,是的,update 操作已记录在binlog,并且我们看到了COMMIT。MySQL对于非事务表发起的事务是不买账的。此时在从库查询,会看到变更了的记录。
我们再看第二种情况,假设coder在事务操作中认为处理的都是事务表,而事实上中间夹杂了非事务表,会出现神马情况?
2.1 对于支持事务的InnoDB表 b 发起事务,看似一切正常。
2.2 好的,事务顺利进行,我们可以提交commit了。我们解析一下主库的binlog。嗯,很好。虽然在事务过程中间操作了非事务表 x ,但是结果还是我们想要的,数据写入了。是的,从库查询也正常。
2.3 可是,事务中间发生了变更,我们得回滚rollback。
Warning (Code 1196): Some non-transactional changed tables couldn't be rolled back
OMG~~ 对非事务表 x 的变更无法回滚了。嗯,主从上查询,insert x 表的记录多了一条。对b 表的变更取消了。但是,MySQL并不将相关记录写入binlog。也就是说从库并不知道主库 x 表记录的增加。从库上是查不到 x 表新增的记录的。对于DBA来说,杯具上演,可怕的主从数据不一致发生了。
再回到 binlog_direct_non_transactional_updates 参数;现在我们可以对他有个比较清晰的认识了,这个参数默认是关闭的。我们开启他,这样不管任何情况对非事务表的操作都将记录binlog。规避了类似#2.3 引起的主从数据不一致的操作。
具体可见官方有详解:
http://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html#sysvar_binlog_direct_non_transactional_updates