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 threa
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 inform
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
>
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
INTERACTIVE_TIMEOUT
WAIT_TIMEOUT
NET_WRITE_T
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 have
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 whi
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.
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 t
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
On Mon, May 25, 2009 at 11:19 AM, Per Jessen 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 i
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
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
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 unsubscrib
just a thought: Did you run "mysql_upgrade" after the import?
On Mon, May 25, 2009 at 10:19 AM, Per Jessen 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.
>
> The
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. I
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".
16 matches
Mail list logo
