MySQL Bugs: #17008: API node crashes on import

Bug #17008	API node crashes on import
Submitted:	1 Feb 2006 15:26	Modified:	16 Mar 2006 16:35
Reporter:	Arne Hüggenberg	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	mysql-5.1-new	OS:	Linux (Gentoo Linux AMD64)
Assigned to:		CPU Architecture:	Any

Description:
current bk checkout of mysql-5.1-new branch
freshly setup mysqld (mysql_install_db)
ndbd --initial
Import Dump 
API node crashes

How to repeat:
Happens on every import

some mysqlbug output

Attachment: mysql_bug (application/octet-stream, text), 3.54 KiB.

category cluster not available when initially reporting

happens only when tables are NDB

What are any errors in the error logs?

Starting a new cluster (--initial) when mysqld has open references to cluster tables can cause problems.

Stopping mysqld, ndb --initial, start mysqld
should fix your problem.

unfortunatly it doesent, the mysqld were freshly started in each test.

db2a ~ # ndb_mgmd-501 -f /var/lib/mysql-cluster/config.ini
db2a ~ # ndbd-501 --initial
db2b ~ # ndbd-501 --ndb-connectstring=xxx.xxx.xxx.xxx --initial
db2a ~ # /etc/init.d/mysql-501 start
db2b ~ # /etc/init.d/mysql-501 start
db2a ~ # ndb_mgm-501
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=2    @xxx.xxx.xxx.xxx  (Version: 5.1.6, Nodegroup: 0, Master)
id=3    @xxx.xxx.xxx.xxx  (Version: 5.1.6, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @xxx.xxx.xxx.xxx  (Version: 5.1.6)

[mysqld(API)]   2 node(s)
id=4    @xxx.xxx.xxx.xxx  (Version: 5.1.6)
id=5    @xxx.xxx.xxx.xxx  (Version: 5.1.6)

db2b mysql-cluster # mysql-501 --socket /var/run/mysqld/mysqld.sock < statistik_handball_entwicklung.ndb
ERROR 2013 (HY000) at line 302: Lost connection to MySQL server during query

API doing the import has crashed at this point

okay - please post the backtrace from the mysqld crash. You can get instructions for submitting a correct backtrace from the manual.

updated the bk tree today, issue persists.

Heres my first try at producing a backtrace, hope i didnt mess it up too bad ;-)

Couldn't reproduce this locally (SuSE 9.3 x86) or on our 64bit test machines running RHEL on amd64

Issue persists after updating both the System and the MySQL Src Tree today

Should i redo the gdb dumps with the new Version?
Were they useful in the first place?
Anything else?

the actual gdb dump

Attachment: mysqld_gdb.log (application/octet-stream, text), 7.59 KiB.

Just noticed i uploaded the wrong file yesterday

After some additional testing today i have some further observations:

Dump, around line 302 (where the import crashes)

CREATE TABLE `spieler_detail_long` (
  `pk_spieler_detail_long` int(11) NOT NULL auto_increment,
  `fk_spieler` int(11) NOT NULL default '0',
  `fk_spieler_attrib` int(11) NOT NULL default '0',
  `eintrag` text,
  PRIMARY KEY  (`pk_spieler_detail_long`)
) TYPE=NDB;

leads to the already described crash of the Importing mysqld.

Changing it to

CREATE TABLE `spieler_detail_long` (
  `pk_spieler_detail_long` int(11) NOT NULL auto_increment,
  `fk_spieler` int(11) NOT NULL default '0',
  `fk_spieler_attrib` int(11) NOT NULL default '0',
  `eintrag` varchar(255),
  PRIMARY KEY  (`pk_spieler_detail_long`)
) TYPE=NDB;

the Import works fine.

For the time being i'd call this an acceptable workaround for me.

Hi,

I retested on latest bk-source (2006-03-14, 5.1.8) wo/ problem.

There has been a lot of bug fixes done in this area of the code, so I suspect
  that this issue has been fixed.

Can you please test it again...

/Jonas

Just verified that issue is fixed on current BK Tree.