MySQL Bugs: #34006: binlog race for temporary ndb table

Bug #34006	binlog race for temporary ndb table
Submitted:	23 Jan 2008 13:01	Modified:	23 Jan 2008 13:13
Reporter:	Tomas Ulin	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Cluster: Replication	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.3	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
when implementing wl#4225 create/alter/drop tables are so fast that they happen before data reaches the binlog

How to repeat:
run rpl_ndb_2myisam and uncomment workaround

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/41151

ChangeSet@1.2841, 2008-01-23 14:03:37+01:00, tomas@poseidon.ndb.mysql.com +3 -0
  disable temp table usage as tes need disk persistant tables
  workaround for bug#34006

../client/mysqlbinlog var/log/master-bin.000001

... error in binlog (wrong name in table map):

#080123 14:12:47 server id 1  end_log_pos 7076  Table_map: `test`.`#sql2-5272-3` mapped to number 28
#080123 14:12:47 server id 1  end_log_pos 7138  Table_map: `mysql`.`ndb_apply_status` mapped to number 16
#080123 14:12:47 server id 1  end_log_pos 7197  Write_rows: table id 16
#080123 14:12:47 server id 1  end_log_pos 7631  Delete_rows: table id 28 flags: STMT_END_F

Documented bug fix for 5.1.23-ndb-6.3.8 as follows:

        Consecutive DDL statements involving tables (CREATE
        TABLE, ALTER TABLE, and
        DROP TABLE) could be executed so quickly that
        previous DDL statements upon which they depended were not yet
        written in the binary log.  
      
      
      
        For example, if DROP TABLE foo was issued
        immediately following CREATE TABLE foo, the
        DROP statement could fail because the
        CREATE had not yet been recorded.

Left bug status as Verified pending further commits/merges.