Bug #59396 The ndbmtds take too long time to start
Submitted: 10 Jan 2011 16:09 Modified: 12 Nov 2016 5:01
Reporter: Geir Green Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-5.1.51 ndb-7.1.9a OS:Solaris (s10x86)
Assigned to: CPU Architecture:Any
Tags: timeout
Triage: Triaged: D3 (Medium) / R6 (Needs Assessment) / E6 (Needs Assessment)

[10 Jan 2011 16:09] Geir Green
The ndbmtds never start in a plain "start cluster" with 
1 ndb_mgmd, 1 ndbdmtd(#2) and 1 mysqld on nanna13 and 
1 ndbdmtd(#3) on nanna10.

The log for node 2 is full of "[ndbd] WARNING  -- Ndb kernel thread <n> is stuck in: ..."

How to repeat:
[10 Jan 2011 16:16] Geir Green
attached logs and config files

Attachment: bug_59396.tar.gz (application/x-gzip, text), 6.67 KiB.

[7 Feb 2011 13:31] Bernd Ocklin
Is this something happening on nanna only? Is this a one-time thing or does it occur often?

I see missed heartbeat in the logs which indicates hardware issues or a machine where processes are not getting scheduled.
[7 Jul 2011 13:24] Andrew Morgan
I've seen this issue as well when using MCM to try and start up a Cluster where all of the nodes are within a single (small) 64 bit Fedora 15 VM running on Virtual Box. After shutting down the VM, allocating more resources (4 cores and 2 Gbytes of RAM) and then restarting the VM I was able to start the Cluster with no problems.

I used MCM 1.1.1 and Cluster 7.1.14

Looks like we need better handling of how things (MCM and/or Cluster) behave when resources are restricted.
[12 Nov 2016 5:01] Bogdan Kecman

Looking at the logs all I can see is high cpu load. Taken that this is a very old release and that in the meantime we improved the startup time of a cluster significantly I doubt this is still valid bug report. In any way - not reproducible on modern hw with modern mccge releases.

all best
Bogdan Kecman