MySQL Bugs: #62847: mysqld node crashes after online add node procedure.

Bug #62847	mysqld node crashes after online add node procedure.
Submitted:	20 Oct 2011 16:25	Modified:	12 Sep 2013 13:38
Reporter:	Matthew Montgomery	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	ndb-7.2.1	OS:	Any
Assigned to:	MySQL Verification Team	CPU Architecture:	Any

Description:
BLOCK NO: 252 sig 143
111020 10:53:33 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=11
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346679 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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 = (nil) thread_stack 0x40000
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(my_print_stacktrace+0x32)[0x83dfd2]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(handle_segfault+0x469)[0x570859]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc60)[0x7f17ab198c60]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f17aa346d05]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x186)[0x7f17aa34aab6]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(_ZN17TransporterFacade14deliver_signalEP12SignalHeaderhPjP16LinearSectionPtr+0x15b)[0xa14b7b]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(_ZN19TransporterRegistry6unpackEPjjt7IOState+0x23d)[0xa7116d]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(_ZN19TransporterRegistry14performReceiveEv+0x189)[0xa29ba9]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(_ZN10ClusterMgr10threadMainEv+0x16c)[0x9e427c]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld(runClusterMgr_C+0x9)[0x9e47d9]
/home/matt/mysql/sandbox/7.2.1/bin/mysqld[0xa43e84]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c)[0x7f17ab18fd8c]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f17aa3f904d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
111020 10:53:34 mysqld_safe Number of processes running now: 0
111020 10:53:34 mysqld_safe mysqld restarted

How to repeat:
Perform online add node but do not restart SQL nodes.  The next query to the SQL node after creating the node group will crash the SQL node, so it becomes kind of an enforced restart procedure.

1) the described procedure is to restart mysqld after nodes has been
   added to config.ini and before the new nodes are started, right ?

2) this behavior (crash) is present also in 7.0, right ?

---

those questions aside...it's still a very valid bug report

Thank you for your bug report. This issue has already been fixed in the latest released version (7.2.2, 7.1.17, 7.0.28) of that product, which you can download at

  http://www.mysql.com/downloads/

Documented fix as follows in the NDB 7.0.28, 7.1.17, and 7.2.2 changelogs:

        When adding data nodes online, if the SQL nodes were not
        restarted before starting the new data nodes, the next query to
        be executed crashed the SQL node on which it was run.