MySQL Bugs: #48009: cluster spends more than 24 hours to recover 7-8 GB with no result

Bug #48009	cluster spends more than 24 hours to recover 7-8 GB with no result
Submitted:	12 Oct 2009 20:53	Modified:	30 Nov 2009 11:59
Reporter:	Tri Pham	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	7.0.6	OS:	Linux (Red Had 4.6 x86_64)
Assigned to:		CPU Architecture:	Any

Description:
Our cluster crashed while we're loading data into the cluster from a dump file. The amount of data in cluster at that time is about 7-8 GB. We restarted, waited for 24 hours with no result. In the end, we had to restarted using --initial option 

How to repeat:
the cluster crashes similar to this  error : http://bugs.mysql.com/bug.php?id=46914

We tried to recover the data afterward by simply restarting all data node process ndbmtd

I have uploaded the ndb_report_error tar zi[ to ftp://ftp.mysql.com/pub/mysql/upload/ with the name of bug-data-48009.tar.bz2

We have in upcoming 7.0.9 made optimizations that in our tests made
restart between 4-70 times faster.

It's probably a good idea to test this...
Which should be released (src) ~ end of this month

Hi,

we have tried several times on several platforms to unpack the file you have uploaded, but it seems to have a corruption in the end. Could you please re-upload ug-data-48009.tar.bz2

The md5sum of the file we have is:

md5sum bug-data-48009.tar.bz2                        
ed07f32acbdf14b69888a19fa4fbda92  bug-data-48009.tar.bz2

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".