Re: bugs Digest 29 Sep 2004 18:58:38 -0000 Issue 636

> -----------------------------------------------------------
> From: Ed Korthof
> Subject: intermittent 'Lost connection to MySQL server' errors w/ DBI
. . .
> Lost connection to MySQL server during query at ./mysql_running line 33.
. . .
> Our my.cnf looks like this:
>
> [mysqld]
> set-variable=max_allowed_packet=10485760
> set-variable=max_connections=355

1. The my.cnf is the same on all boxes? What does "show variables like
'%t_timeout%'" give on at least the box that's broken and one that
isn't? We're looking specifically for "wait_timeout" and
"connect_timeout".

2. Any firewall rules on either box? Find out what, if any, firewall
software you have running. ipfw? iptables? Check the rules. Make sure
nothing is closing "inactive" connections or otherwise closing
connections.

3. Assuming the above turn up no clues, ask your Unix admin (if it isn't
you) to look at the network layer. Packet loss? Transmit errors? All the
usual suspects.

--
timeless



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: bugs Digest 29 Sep 2004 18:58:38 -0000 Issue 636

On Wed, Sep 29, 2004 at 01:38:03PM -0700, philo vivero wrote:
> > -----------------------------------------------------------
> > From: Ed Korthof
> > Subject: intermittent 'Lost connection to MySQL server' errors w/ DBI
> . . .
> > Lost connection to MySQL server during query at ./mysql_running line 33.
> . . .
> > Our my.cnf looks like this:
> >
> > [mysqld]
> > set-variable=max_allowed_packet=10485760
> > set-variable=max_connections=355
>
> 1. The my.cnf is the same on all boxes? What does "show variables like
> '%t_timeout%'" give on at least the box that's broken and one that
> isn't? We're looking specifically for "wait_timeout" and
> "connect_timeout".

There are machines with exactly the same my.cnf which work fine. I did
my testing on a machine where max_connections was slightly higher, but
reducing it to 355 doesn't change the fact that I can't reproduce it on
the other machine.

We did check the timeouts, but the numbers didn't show anything
interesting AFAICT --

| connect_timeout | 5 |
| delayed_insert_timeout | 300 |
| interactive_timeout | 28800 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| wait_timeout | 28800 |

....

> 2. Any firewall rules on either box? Find out what, if any, firewall
> software you have running. ipfw? iptables? Check the rules. Make sure
> nothing is closing "inactive" connections or otherwise closing
> connections.
>
> 3. Assuming the above turn up no clues, ask your Unix admin (if it isn't
> you) to look at the network layer. Packet loss? Transmit errors? All the
> usual suspects.

I'd say the nework isn't the issue because the access is on the same
machine, using a unix domain socket. Sorry, I should have been clearer
about that -- it's in the strace out, but it should have been mentioned
at the top. Otherwise, i'd also have tried tcpdump...

The only thing I haven't tried is strace on the MySQL server, largely
because I'd like to know where to look (or which syscalls are relevant)
-- there's too much output for this to be useful without some way to
pare down the amount of data.

.... also, that might make it harder to reproduce -- I should have
mentioned one more thing: turning on MySQL query logging made it harder
to reproduce this. It was still possible, but I had to increase the
loop I used for this from 450 (1000 was more than enough).

We did the calls with bash loops, but it's as easy w/ perl:

perl -e 'foreach $i (1..1000) { system("./mysql_running &"); }'

....

thanks --

Ed

--
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
| Ed Korthof | edk@collab.net | 650-228-2527 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

ON UPDATE CURRENT_TIMESTAMP should appear in SHOW FULL COLUMNS output

Hi,
ON UPDATE CURRENT_TIMESTAMP should appear in Extra column of SHOW FULL
COLUMNS output.
MySQL version: 4.1.5-gamma-log
Thank you,
Sasha


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org