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:
Category:MySQL Cluster: Replication Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.3 OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[23 Jan 2008 13:01] Tomas Ulin
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
[23 Jan 2008 13:03] 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:


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
[23 Jan 2008 13:13] Tomas Ulin
../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
[1 Feb 2008 13:07] Jon Stephens
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.