【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

　　

[MySQL] 【MySQL】 binlog_direct_non_transactional_updates 参数的用法

相关帖子

MySQL数据库如何给表设置约束详解

MySQL Server 层和存储引擎层是怎么交互数据的？

MySQL让人又爱又恨的多表查询

MySQL存储过程图文实例讲解

MySQL由浅入深掌握连接查询

MySQL数据库触发器从小白到精通

一篇带给你MySQL索引知识详解

MySQL视图和索引专篇精讲

阿里面试MySQL死锁问题的处理

mysql中drop、truncate与delete的区别详析

上山打老虎 LV4