Description:
mysqlimport loses connection to MySQL server during large imports. I've checked the documentation as best as possible, and could not solve this problem. Command as follows:
mysql > mysqlimport -u mysqldba -d homo_sapiens_core_17_33 -p *.txt.table
The import works OK on most tables (less than 1M rows), but loses connection during import of a few select tables of files sizes of 300-500MB. Tried to perform a backtrace according to your site instructions.
The mysqld.log file reports the following :
mysqld got signal 11;
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=268431360
record_buffer=1044480
sort_buffer=1048568
max_used_connections=1
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation
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 range sanity check OK, backtrace follows:
0x80ec0ac
0x4003f929
0x4003db3d
0x4003a443
0x82e3972
0x82e37d6
0x8152833
0x815250f
0x82dd032
0x82dcec5
0x82dcc83
0x82d85a5
0x813c258
0x813c3c5
0x81507d5
0x80f44cb
0x80f6693
0x80f1ff3
0x80f15d8
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x83e1cd8 = LOAD DATA INFILE '/home/naxelrod/ensembl_db/protein_align_feature.txt.table' INTO TABLE protein_align_feature
thd->thread_id=3
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 3 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash
I followed these instructions to perform a backtrace which reported:
bash-2.05b$ resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
0x80ec0ac + 135184556
0x4003f929 + 1074002217
0x4003db3d + 1073994557
0x4003a443 + 1073980483
0x82e3972 + 137247090
0x82e37d6 + 137246678
0x8152833 + 135604275
0x815250f + 135603471
0x82dd032 + 137220146
0x82dcec5 + 137219781
0x82dcc83 + 137219203
0x82d85a5 + 137201061
0x813c258 + 135512664
0x813c3c5 + 135513029
0x81507d5 + 135595989
0x80f44cb + 135218379
0x80f6693 + 135227027
0x80f1ff3 + 135208947
0x80f15d8 + 135206360
I have no idea what to do with the backtrace info.
How to repeat:
You can download the latest version of the human genome via anonymous ftp at:
ftp.ensembl.org/pub/current_human/data/mysql/
Download the schema and some of the larger files such as protein_align_feature.txt.table.gz and repeat_feature.txt.table.gz. Decompress the files and load the database using mysqlimport.
Suggested fix:
I don't know.
