Hi there,
I am trying to sort through an occasional problem I am having with
deadlocks I am facing with a series of inoodb tables:
cases (PK id)
|___ cases_workcodes (PK id, case_id / FK case_id)
|___ cases_invoices (PK id, case_id / FK case_id)
|___ cases_additional (PK id, case_id / FK case_
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
Does 5.0.45 honor absolute path in bin-log? I got a warning when I
tried it and docs say default handling was problematic and was fixed
in 5.0.51
Thanks
Hitesh
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch
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
MySQL Replication: Walk-through of the new 5.1 and 6.0 features
http://forge.mysql.com/wiki/MySQL_Replication:_Walk-through_of_the_new_5.1_and_6.0_features
This Thursday (May 28th, 14:00 UTC), Lars Thalmann will give a MySQL
University session on MySQL Replication: Walk-through of the new 5.1 and
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".
cannot help with implementation details unless we see your DB schema e.g.
mysql>use DB
mysql>show tables
msqyl>desc table1
mysql>desc table2
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht is
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
19 matches
Mail list logo
