Jason Wilkinson wrote:
While I don't necessarily plan on restructuring my servers often enough
that having to create a new host entry on the machine(s) each time a dns
entry changes would be anything but an annoyance and another point of
failure. This is the dns check against the client. so if i add a new
server now I don't just add it to the zone file I have to go add it on
all of my mysql servers... defeats the purpose. About the only way that
using the host file in a decent sized cluster would be easy would be if
it was hosted on a share, or pushed out with a script... how many
failure points do we want to add?
Greg Swift wrote:
Dallas L. Engelken wrote:
From: ISP Lists [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 24, 2005 10:21 AM
Subject: Re: [vchkpw] Spotty behavior authenticating: MySQL server
has gone away
Something peculiar happened to mysql during a reboot and
authdaemond is having trouble completing authentications....
Aug 24 08:36:15 hostname authdaemond: vmysql: sql error: MySQL
server has gone away
This problem is spotty though. I have several successful
authentications before this error occurs. I then have to restart
mysqld before I can get any other authentications to succeed. I am
still able to use the mysql client to connect to the server
for an interactive session.
What seems strange to me is that there are only two mysql
root 23923 0.0 0.1 5060 1108 pts/0 S 09:13
mysql 23956 0.0 0.5 38620 5656 pts/0 Sl 09:13 0:00
/usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib
Every other instance of mysql 3.23.x I've ever run has
about 10 child
threads running, so this seems strange to see only one child
I have not updated any packages on this box recently. None
at all, I
Suggestions to investigate? Googling on the "MySQL server
has gone away"
is a wild goose chase.
Hrm, rebooting the box seems to have helped. Still same
number of mysql daemons, but they're answering now... Damned
strange. dmesg on reboot didn't show any ext3 errors being
fixed - I was wondering if this was a disk thing.
Thoughts still welcome and appreciated on this.
Well.. just for reference (cause it took me a while to figure this one
out)... if your box is running with multiple name servers configured
for resolution, and the primary stops responding, you will see this
same issue. What happens is the slight delay added to the auth
sequence as the mysql fails to the secondary resolver causes the
vpopmail to fail the connection.
To be more specific this will occur:
1: primary name server fails
2: When authentication to DB it takes a longer time due to system
having to fail to secondary resolver.
3: vpopmail's auth to db starts failing due to timeouts (mysql takes
to long to respond, but does respond), vpopmail tries harder to
connect to db, connection count sky rockets (I saw upwards of 1400
connections) and in turn the connections do not close properly.
4: db locks up hard.
5: once you quiet down vpopmail (easiest way was to disable incoming
access sadly), test messages show that an occasional message wil lgo
through, but the rest receive the "MySQL server has gone away"
6. Trying to auth to db, albeit slightly slower than normal, responds
and allows auth. Once in runs perfectly.
7. You realize that its primary dns server is off for whatever reason,
start it, and voila no problem.
Now admittedly, previously I've seen the same thing but for other
reasons, this was just the more obscure annoying one.
Yes I realize that a local dns server make a lot of sense for this
situation, but if the named on that box stops, and it has your other
name servers as secondary, WHEN are you gonna realize that? Most
people would not add that to their monitoring. LOTS of fun.
Or, I would think, you could just add the server/client to the hosts file(s)
and skip DNS entirely. Or use IP addresses.