Per Jessen wrote:
It happened agaIn this morning, but slightly different:
[snip]
thd=0x7fe0140c7e00
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,
Per Jessen wrote:
I have just discovered that my mysql server was restarted this
morning, which is what gave me the 2013. In the log I found this:
[snip]
It happened agaIn this morning, but slightly different:
[snip]
thd=0x7fe0140c7e00
Attempting backtrace. You can use the following
This weekend we completed migrating a large(ish) mysql server from
5.0.26 on 32bit to 5.0.51a on 64bit. Everything went relatively
smoothly, until this morning when I noticed an application had choked
on getting Error 2013 Lost connection to MySQL server during query.
The application is running
Per Jessen wrote:
This weekend we completed migrating a large(ish) mysql server from
5.0.26 on 32bit to 5.0.51a on 64bit. Everything went relatively
smoothly, until this morning when I noticed an application had choked
on getting Error 2013 Lost connection to MySQL server during query.
I
Michael Dykman wrote:
It might be helpful if you could tell us how you affected your data
migration
Sorry, I'm not familiar with reporting problems in/on mysql.
The data migration was done with a full database dump (mysqldump) from
the 32bit system, then a reload on the new 64bit system.
just a thought: Did you run mysql_upgrade after the import?
On Mon, May 25, 2009 at 10:19 AM, Per Jessen p...@computer.org wrote:
Michael Dykman wrote:
It might be helpful if you could tell us how you affected your data
migration
Sorry, I'm not familiar with reporting problems in/on mysql.
Michael Steinfeld wrote:
just a thought: Did you run mysql_upgrade after the import?
No, I didn't - I didn't think of it as I really only moved the data
across.
best regards
Per Jessen, Zürich
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
Per Jessen wrote:
Michael Steinfeld wrote:
just a thought: Did you run mysql_upgrade after the import?
No, I didn't - I didn't think of it as I really only moved the data
across.
Okay, have done a mysqlcheck --check-upgrade - came back all clean. I
don't see a need to run
Have you tried running the offending SQL manually against you new
installation? Does it come back clean in the isolated case? Is there
anything else which runs against this database at night? crons?
Could you post the script that you are running to give some context to
the statement which winds
On Mon, May 25, 2009 at 11:19 AM, Per Jessen p...@computer.org wrote:
Per Jessen wrote:
Michael Steinfeld wrote:
just a thought: Did you run mysql_upgrade after the import?
No, I didn't - I didn't think of it as I really only moved the data
across.
I suspect that will solve your issue.
Michael Dykman wrote:
Have you tried running the offending SQL manually against you new
installation? Does it come back clean in the isolated case?
No, not manually, but the job/the SQL is run several times a day, maybe
2-3 times per hour.
Is there anything else which runs against this
Per Jessen wrote:
Michael Dykman wrote:
Have you tried running the offending SQL manually against you new
installation? Does it come back clean in the isolated case?
No, not manually, but the job/the SQL is run several times a day,
maybe 2-3 times per hour.
I've also just run the query
Given the new hardware, I'm now suspecting the RAID controller. I have
seen misconfigured RAIDs or bad RAID drivers take out a server in just
such a manner. I had a debian server connected to an EMC SAN.. As
debian isn't supported, we had this open-source driver which gave us
no end of problems.
Michael Dykman wrote:
Given the new hardware, I'm now suspecting the RAID controller. I have
seen misconfigured RAIDs or bad RAID drivers take out a server in just
such a manner. I had a debian server connected to an EMC SAN.. As
debian isn't supported, we had this open-source driver which
The issues that we saw only came to light under stress. The
application I am referring to ran under a fair bit of load at the best
of times but it was during sustained spikes that the flaws in our
driver made themselves apparent.
Mind you, we weren't using JFS, so I'm not sure how that would
an application had choked
on getting Error 2013 Lost connection to MySQL server during query.
The application is running remotely on 32bit using mysql library from
version 5.0.67.
I've been googling quite a bit, but haven't really found anything of any
use. I've checked the two configurations
Darryle Steplight wrote:
Hi Per,
Maybe you need to beef up your CONNECT_TIMEOUT setting in your .my.cnf
file. Are these queries appearing in your slow query logs?What is your
LOG_QUERY_TIMES set too?
Here are some other settings you may want to play around wtih
CONNECT_TIMEOUT
17 matches
Mail list logo
