| Bug #16206 | Superfluous COMMIT event in binlog when updating BDB in autocommit mode | ||
|---|---|---|---|
| Submitted: | 4 Jan 2006 22:19 | Modified: | 3 Jul 2006 19:41 |
| Reporter: | Guilhem Bichot | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
| Version: | 5.0 | OS: | Linux (linux) |
| Assigned to: | Chad MILLER | CPU Architecture: | Any |
[1 Jun 2006 13:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/7160
[1 Jun 2006 13:39]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/7164
[1 Jun 2006 23:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/7190
[12 Jun 2006 12:55]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/7536
[12 Jun 2006 19:34]
Chad MILLER
Pushed to 5.0.23 (in maint team tree).
[26 Jun 2006 18:06]
Chad MILLER
No doc is necessary, I believe. This would have caused unnecessarily large binlogs, but should not have been a problem otherwise.
[27 Jun 2006 10:52]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/8311
[3 Jul 2006 17:49]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/8654
[3 Jul 2006 19:41]
Paul DuBois
No changelog entry needed.
[3 Jul 2006 23:04]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/8666
Description: I used this test (derived from blackhole.test): --disable_warnings drop table if exists t1,t2; --enable_warnings reset master; create table t1 (a int) engine=blackhole; show create table t1; insert into t1 values(1); let $VERSION=`select version()`; --replace_result $VERSION VERSION --replace_column 2 # 5 # show binlog events; drop table t1; With SHOW CREATE TABLE I could verify that the table is really created as blackhole (and as other engines, see below). I also verified that autocommit is 1. The resulting binlog when engine is blackhole, has for the INSERT (before that, there is the CREATE TABLE): # at 205 #051215 22:08:02 server id 1 end_log_pos 87 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1134680882; insert into t1 values(1); When engine is BDB: # at 199 #051215 22:11:48 server id 1 end_log_pos 87 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1134681108; insert into t1 values(1); # at 286 #051215 22:11:48 server id 1 end_log_pos 355 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1134681108; COMMIT; When engine is InnoDB: # at 202 #051215 22:13:46 server id 1 end_log_pos 87 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1134681226; insert into t1 values(1); # at 289 #051215 22:13:46 server id 1 end_log_pos 316 Xid = 6 COMMIT; And when engine is MyISAM: # at 202 #051215 22:19:56 server id 1 end_log_pos 289 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1134681596; insert into t1 values(1); In 5.1, the binlog for blackhole is the same as the binlog for BDB I showed above (understandable as blackhole has has_transactions()==1 in 5.1 only). Nowhere is there a BEGIN Query_log_event. The COMMIT Query_log_event is redundant for blackhole and BDB (as the INSERT is autocommit: there is no BEGIN in binlog; when slave comes to the COMMIT event it has already committed, so there is nothing to commit, this COMMIT is a guaranteed null operation on slave). (69 bytes used in binlog for nothing). On the other hand, the Xid_log_event for InnoDB is NOT redundant (note that it's an Xid_log_event, needed to maintain consistency between binlog and InnoDB in case of crash). How to repeat: see above. Suggested fix: Serg and Guilhem discussed this problem and the consensus seems to be on changing the two last lines of binlog_commit() (log.cc) from Query_log_event qev(thd, STRING_WITH_LEN("COMMIT"), TRUE, FALSE); DBUG_RETURN(binlog_end_trans(thd, trans_log, &qev)); to if (all) // a real transaction so we need a COMMIT mark for slave to commit { Query_log_event qev(thd, STRING_WITH_LEN("COMMIT"), TRUE, FALSE); DBUG_RETURN(binlog_end_trans(thd, trans_log, &qev)); } else // an autocommit statement DBUG_RETURN(binlog_end_trans(thd, trans_log, 0)); It is an absolutely untested suggestion. The developer should check it and it should be reviewed, of course.