I just upgraded my 64-bit server from Ubuntu 10.04 to 12.04.1 not quite two weeks ago. Since then this issue has only come up twice in the Apache error log and no logs seem to have any entries pointing to a cause:

There were some grumblings in the mysql error log for "Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT" but that was an insert query that used a subselect on a different table to get the insert value. I split it up into two queries. Other than that, the mysql error log only shows entries for when I restarted mysql.

I have a second server configured the exact same and it doesn't have the issues, but it was upgraded over a month ago and doesn't have the user or data volume.

No other logs in /var/log mention anything for the time when the db was unavailable to php. Mysql was still running, though. Php just couldn't get to it.

The fact that a MySQL restart solves the problem makes me suspect a problem with MySQL rather than PHP. When this problem happens, are you able to connect to MySQL manually via the command line?

I pass TRUE as the 4th param, as the code sometimes connects to a remote database for importing content.

The fourth parameter to mysql_connect has nothing to do with connecting to remote databases. It could be the source of your problem, but only if your code is calling mysql_connect more than once in a request.

Also note that PHP's mysql library is deprecated, although at the moment still supported. This is probably not related to the problem either, but switching to a more modern library might solve the problem.

The fact that a MySQL restart solves the problem makes me suspect a problem with MySQL rather than PHP. When this problem happens, are you able to connect to MySQL manually via the command line?

The fourth parameter to mysql_connect has nothing to do with connecting to remote databases. It could be the source of your problem, but only if your code is calling mysql_connect more than once in a request.

Also note that PHP's mysql library is deprecated, although at the moment still supported. This is probably not related to the problem either, but switching to a more modern library might solve the problem.

The code does sometimes connect to more than one database server on a single page, that's why I use the fourth param. I just didn't word that bit very clearly. The code is the same on all of my live servers, however.

I have thought about updating to use mysqli, but haven't had the time to test. PDO seems to be a bit slower that mysqli and mysql_* in benchmarks, but the benchmark tests I've seen were a couple of years old.

Our Zabbix server didn't report mysql as down and, if I recall correctly, I could connect to mysql via the command line.

I just upgraded my 64-bit server from Ubuntu 10.04 to 12.04.1 not quite two weeks ago. Since then this issue has only come up twice in the Apache error log and no logs seem to have any entries pointing to a cause:

There were some grumblings in the mysql error log for "Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT" but that was an insert query that used a subselect on a different table to get the insert value. I split it up into two queries. Other than that, the mysql error log only shows entries for when I restarted mysql.

I have a second server configured the exact same and it doesn't have the issues, but it was upgraded over a month ago and doesn't have the same user or data volume.

No other logs in /var/log mention anything for the time when the db was unavailable to php/Apache. The Mysql process was still running, though. Php just couldn't get to it.

Is there anywhere else I can look to see what causes this?

### Update from 1/2/2013

Well, it's happened a few times since my last post. It happened at 9AM today and I got en error number in the Apache error log, but haven't been able to find much to help me with it:

Since I was there, I restarted Apache first to see if it was the culprit (unclosed handles), but it didn't help. A mysql restart did the trick, but i could have just waited a few minutes for it to resolve itself like it has done every other time. I didn't think to make sure that the socket file was still there.

Assuming 2 is file not found, 95 is operation not supported (which may not be an error), and 111 is connection refused, it sounds like MySQL isn't keeping the socket alive.

Can you change the database connection settings to use 127.0.0.1 instead of localhost? As a test.

[edit] I assume that you've been checking each time that mysqld was still running?

Thanks for the reply, requinix!

I tested on a dev server and then on the affected server and 127.0.0.1 worked just as well as localhost in the connection params for both.

You know, I don't think I'd checked for the process. I may have, but I don't recall. I've been logged into the mysql prompt when it started and was able to hit enter for a new line, but further testing shows me that I'll get a new line even if I stop mysqld while at the mysql prompt. I'll check for the process the next time I see this happening.

Wonder why MySQL wouldn't be keeping the socket alive. It seems to take a bit more than 6 minutes for it to resolve itself when I'm not on top of it.