Bug #67256 altering a locked table crashes binlogging mysqlds
Submitted: 16 Oct 2012 8:39 Modified: 13 Aug 2014 11:36
Reporter: Hartmut Holzgraefe Email Updates:
Status: Verified Impact on me:
Category:MySQL Cluster: Replication Severity:S2 (Serious)
Version:mysql cluster 7.2.6 OS:Linux
Assigned to: CPU Architecture:Any

[16 Oct 2012 8:39] Hartmut Holzgraefe
trying to ALTER a cluster table that has been locked with LOCK TABLE on another binlogging mysqld will crash that other mysqld

I know that LOCK TABLE isn't the best idea with cluster as the locks are only local to the current mysqld and not distributed throughout the cluster, but still things should not crash if locks are used ...

Error log will look like this:

121012 13:34:11 [Note] NDB Binlog: logging ./test/t1 (UPDATED,USE_WRITE)
121012 13:35:55 [Note] NDB Binlog: DISCOVER TABLE Event: REPL$test/t1
12:35:55 UTC - mysqld got signal 11 ;
Thread pointer: 0x7f2e200009b0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f2ed80c1ea8 thread_stack 0x20000

How to repeat:
* Set up a cluster with at least two mysqld nodes
* At least one of the mysqlds needs to have log-bin enabled 
* Create a test table with engine=ndbcluster
* On the binlogging mysqld do a LOCK TABLE on that table
* On the other mysqld do an "ALTER TABLE $table ENGINE=ndb"; (or any other non-online ALTER operation)
* The binlogging mysql will now crash
[8 Nov 2012 5:34] MySQL Verification Team
Hello Hartmut,

Thank you for the report.

Verified as described on reported and later versions.

[13 Aug 2014 11:36] Hartmut Holzgraefe
Seems to be fixed, can't reproduce in 7.2.13, 7.3.6 ...?