Hey,
We just got a new Dell Poweredge 6450 preloaded with redhat 6.2. Our intention
is to move the database off a smaller machine and load it into this one. We
currently have MySQL 3.23.38 using the innobase driver on redhat 6.2 with kernel
2.4.4. This is on a dual PIII650 with 1 gig of ram and it runs fine. Here is a
copy of a status readout in mysql:
mysql Ver 11.15 Distrib 3.23.38, for pc-linux-gnu (i686)
Connection id: 232107
Current database:
Current user: root@localhost
Current pager: stdout
Using outfile: ''
Server version: 3.23.38
Protocol version: 10
Connection: Localhost via UNIX socket
Client characterset: latin1
Server characterset: latin1
UNIX socket: /tmp/mysql.sock
Uptime: 1 day 19 hours 23 min 39 sec
Threads: 55 Questions: 70609984 Slow queries: 15 Opens: 203 Flush tables: 1
Open tables: 155 Queries per second avg: 451.994
As you can see we have quite a load on this poor machine, this is why we wanted
to move to a bigger badder machine so we could push more out of MySQL. Anyway,
as mentioned before, our machine is a Poweredge 6450 with 4 Xeon 750mhz
processors and 4gb of ram. We also have a dell 4 channel PercRaid card that does
a raid 5 onto 4 36gb scsi disks. So we loaded Mysql 3.23.38 onto the machine
with no extra tweeks, just with the raw install from dell, setup the Innobase
driver and imported our data. Once we moved the site onto the new server
everything worked great, we could do super heavy queries in no time, it was
great! Then a day later I was looking at the .err log and noticed that MySQL had
crashed several times! Each time it crashes it restarts itself and the innobase
tables fix themselves. Innobase is verry cool! But this is a real problem!
So I took the .err file and parsed the stack trace against the symbol file for
mysql like the manual says. Here is a copy of the .err file with the stack dump
from one crash. This one is from kernel 2.4.3:
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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:
0x81c508a
0x80f4ca5
0x80f44d4
0x80f823e
0x80f4021
0x80caee6
0x80c4a2d
0x809bdbf
0x8097de1
0x8097522
0x8098177
0x80abede
0x8084967
0x80877fd
0x8082ba9
0x80820d6
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xb91044a8 is invalid pointer
thd->thread_id = 6230
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 6230 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to [EMAIL PROTECTED]
Number of processes running now: 0
010516 15:55:52 mysqld restarted
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 2512947858
InnoDB: Doing recovery: scanned up to log sequence number 0 2512963
Here is the results of running stackresolve:
[root@cobalt /tmp]# /usr/local/mysql/bin/resolve_stack_dump -s /tmp/mysqld.sym
-n /tmp/mysql.stack
0x81c508a pthread_sighandler + 150
0x80f4ca5 dict_col_add_to_cache + 153
0x80f44d4 dict_table_add_to_cache + 1128
0x80f823e dict_load_table + 3326
0x80f4021 dict_table_get + 169
0x80caee6 open__11ha_innobasePCciUi + 310
0x80c4a2d ha_open__7handlerPCcii + 33
0x809bdbf openfrm__FPCcT0UiUiUiP8st_table + 4959
0x8097de1 open_unireg_entry__FP3THDP8st_tablePCcN22b + 69
0x8097522 open_table__FP3THDPCcN21Pb + 950
0x8098177 open_ltable__FP3THDP13st_table_list13thr_lock_type + 71
0x80abede
mysql_insert__FP3THDP13st_table_listRt4List1Z4ItemRt4List1Zt4List1Z4Item15enum_duplicates13thr_lock_type
+ 302
0x8084967 mysql_execute_command__Fv + 5339
0x80877fd mysql_parse__FP3THDPcUi + 209
0x8082ba9 do_command__FP3THD + 1305
0x80820d6 handle_one_connection__FPv + 578
We have tried 2.2.x kernels and all kinds of memory configs but we are at a
loss for what to do. It seems to be a machine problem because the same data on a
different machine works fine. If anyone has any ideas I would love it! Thanks.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
