Bug #19536 NDB replication fails when no explicit--binlog-format given
Submitted: 4 May 2006 12:20 Modified: 4 May 2006 18:14
Reporter: Kristian Nielsen Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S2 (Serious)
Version:5.1.10 (latest bitkeeper) OS:Any (All)
Assigned to: Antony Curtis CPU Architecture:Any

[4 May 2006 12:20] Kristian Nielsen
Description:
After the push of WL#3201, NDB replication fails if no explicit --binlog-format=row is given.

How to repeat:
$ mysql-test-run.pl rpl_ndb_UUID
rpl_ndb_UUID                   [ fail ]

Errors are (from /dev/shm/v4/log/mysqltest-time) :
mysqltest: In included file "./extra/rpl_tests/rpl_row_UUID.test": At line 75: command "diff $MYSQLTEST_VARDIR/tmp/rpl_row_UUID_master.sql $MYSQLTEST_VARDIR/tmp/rpl_row_UUID_slave.sql;" failed

Note that these both work as expected:

$ mysql-test-run.pl --binlog-format=row rpl_ndb_UUID
$ mysql-test-run.pl --binlog-format=statement rpl_ndb_UUID

Suggested fix:
The problem seems to be that the WL#3201 patch changes the initialization order, so that the processing of the binlog-format in NDB and in the main server are no longer working together.
[4 May 2006 17:26] 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/5964
[4 May 2006 18:14] Antony Curtis
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Pushed to 5.1.10-beta repository
[2 Oct 2006 16:54] 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/12953

ChangeSet@1.2275, 2006-10-02 12:54:26-04:00, cmiller@zippy.cornsilk.net +3 -0
  Bug#19536: Assert on undefined @uservar in prepared statement execute
  
  The executing code had a safety assertion so that it refused to free Items
  that it didn't create.  However, there is a case, undefined user variables,
  which would put Items into the list to be freed.
  
  Instead, do something that is more risky in expectation that the code will 
  be refactored soon, as Kostja wants to do:  Remove the assertions from 
  prepare() and execute().  Put one assertion at a higher level, before 
  stmt->set_params_from_vars(), which may then create new to-be-freed Items .
[2 Oct 2006 17:17] Calvin Sun
The last patch is for bug#19356, not this one.