【MySQL】 binlog_direct_non_transactional_updates 参数的用法

 【MySQL】 binlog_direct_non_transactional_updates  参数的用法:

这个参数是5.1.44 才引入的，从命名可理解为--非事务直接写binlog 。可怎么觉得不对劲呢，我们知道对于非事务表（如：MyISAM），即使发起了事务begin，而结果不管提交commit，还是回滚rollback；对中间执行了的非事务表的写操作都会记录binlog。

我们看一遍演示：

1.1 对于不支持事务的MyISAM表 x 发起事务操作。

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

©著作权归作者所有：来自51CTO博客作者frostmounre的原创作品，如需转载，请注明出处，否则将追究法律责任

mysql数据库休闲