On 9/03/2006 9:43 a.m., Kishore Jalleda wrote:
could you tell us if these 6 are in a cluster or in a replication set up,
and u also said the 3 linux bixes all crash at once, did u check the logs,
do they crash under load, what about the OS, is it stable when mysql
crashes????
Kishore Jalleda
We use cluster and replication. We were seeing random crashes on the
replication slaves, which are only used for SELECT queries. They
wouldn't all crash at the same time (then again they aren't all doing
the same queries at the same time). No OS problems.
This is what we would get in the error log:
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=134217728
read_buffer_size=1044480
max_used_connections=15
max_connections=100
threads_connected=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
= 335471 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0xaea70058
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...
Cannot determine thread, fp=0x9bb5ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81913f0
0xfbc420
0x827a1c1
0x8279d88
0x827a1c1
0x8279f0d
0x827a03a
0x8278554
0x81a6b39
0x81ae100
0x81a5213
0x81a4d4d
0x81a429e
0x960b80
0x6549ce
New value of fp=(nil) failed sanity check, terminating stack trace!
I did run the backtrace but didn't save the results, now I can't resolve
it without reinstalling mysql 5 because I don't have the right sym file :/
This is using the 5.0.18 Linux RPMs from mysql.com (tried both the
glibc23 and statically linked ones, no difference - the above trace is
from the glibc23 one). Running a mix of both Fedora 3 and Fedora 4 on
Intel P4s.
-Simon
On 3/8/06, Dave Pullin <[EMAIL PROTECTED]> wrote:
I am running MySQL on 6 servers - 3 Linux and 3 Windows. I recently
upgraded
to V5 on all servers. Now MySQL is crashing regularly (several times per
day, some days) with 'got signal 11'.
My 3 Linux servers are very different machines running different software
a uniprocessor Pentium with 512MB running Redhat9 with MySQL 5.0.18-0.i386
, a new dual XEON with 8GB running Fedora Core 4 with 64bit MySQL
5.0.18-0.glibc23.x86_64
, a old quad XEON with 4GB running Fedora Core 4 with MySQL 5.0.18-0.i386
The windows machines are not having a problem. All 6 are running
essentially
the same application.
It seems unlikely to be a hardware problem because its on 3 machines at
once. It looks like a MySQL V5 problem but I can't pin it down to anything
specific enough to report a bug.
Anyone had similar experiences with MySQL V5?
Dave
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
