【MySQL】 binlog_direct_non_transactional_updates 参数的用法

websyhg

　　【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