通过套接字的mysql连接失败

Question

情况是，我们有 AWS EC2 中型实例，上面有 Linux。
它也有 Drupal。除此之外，我们也很少有文件可以访问 mysql，其设置与 Drupal 相同。
问题是 - 在某一时刻 mysql 拒绝连接。
它发生在负载过低或过大时（与此无关），以及一旦无法访问，mysqld 进程仍在运行，并且不会下降。
重新启动此过程并不能解决问题。重新启动实例 - 修复问题。

当我连接到本地主机时，它给出了这个：

Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

当 mysql.sock 文件就位并具有正确的权限时。
重新启动 mysqld 没有帮助，但重新启动实例 - 解决了问题。

my.cnf 看起来像这样：

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

wait_timeout=28800

interactive_timeout = 28800

max_allowed_packet=32M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

mysqld 运行也没有任何错误，在日志中我们有这个：

120830  9:48:00 [Note] /usr/libexec/mysqld: Shutdown complete

120830 09:48:00 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120830 09:48:01 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120830  9:48:01 [Note] Plugin 'FEDERATED' is disabled.
120830  9:48:01 InnoDB: The InnoDB memory heap is disabled
120830  9:48:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120830  9:48:01 InnoDB: Compressed tables use zlib 1.2.3
120830  9:48:01 InnoDB: Using Linux native AIO
120830  9:48:01 InnoDB: Initializing buffer pool, size = 128.0M
120830  9:48:01 InnoDB: Completed initialization of buffer pool
120830  9:48:02 InnoDB: highest supported file format is Barracuda.
120830  9:48:02  InnoDB: Waiting for the background threads to start
120830  9:48:03 InnoDB: 1.1.8 started; log sequence number 4191070086
120830  9:48:03 [Note] Event Scheduler: Loaded 0 events
120830  9:48:03 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.20'  socket: '/var/lib/mysql/mysql.sock -u root'  port: 3306  MySQL Community Server (GPL)

当问题再次出现时，我再次记录日志，尝试停止httpd然后mysqld，然后运行mysqld然后运行httpd，日志与正常情况下的日志完全相同，重启顺序相同。

更改 php.ini 并没有保存情况：

mysql.allow_persistent = Off

按此顺序重新启动，没有帮助（甚至尝试了不同的顺序）：

service httpd stop
service mysqld stop
service mysqld start
service httpd start

我们想知道是什么问题以及如何防止它像那样掉下来。

Answer 1

仅从提到的症状来看，可能会发生以下情况。希望对你有帮助。

您的 PHP 可能使用了未正确关闭的持久数据库连接。一旦达到某个限制，数据库将不再接受新的连接（来自 unix 套接字或网络）。

在php.ini中有与数据库长连接相关的设置，如：

mysql.allow_persistent = Off

mysqld 重启不起作用的事实可能与两件事有关：

1. 重新启动可能与显式service mysqld stop 后跟service mysqld start 不同；此外，您可以在它重新启动时检查日志，看看它是否遇到任何异常情况。

2. 重启顺序可以稍微改变，也包括你的 PHP 设置，所以你应该先停止 apache，然后停止 mysqld；之后，您以相反的顺序启动它们。

Answer 2

浏览一下您的配置：您的超时时间非常高。正如其他人所猜测的那样，我认为您正在尝试使用持久连接。但这些通常不能与标准 ext/mysql(i) 或 ext/PDO` 一起使用。

如果你不想玩new mysqlnd multiplexing plugin 之类的东西（见intro，见FAQ，我建议显着降低wait_timeout 并注意max_connections（在mysqld-侧）当您遇到流量高峰时。

所以wait_timeout 在您的应用程序没有正确处理连接句柄时基本上会释放它们。在 Web 应用程序中，连接空闲超过 10 秒是没有意义的。而且您不希望有很多孤儿连接处于待机状态。

其次，max_connections 变量也很重要，因为仅仅将其提高到 5,000 是不够的——因为虽然这意味着 MySQL 将允许如此多的连接，但它也会分配资源 (RAM) 来处理这些潜在的连接 - 即使您从不需要它们。

在峰值期间，您应该能够使用您的root 帐户连接到 MySQL。这是能够调试服务器的安全措施。我的建议是暂时启用slow-log。

此外，在峰值期间检查进程列表：mysqladmin -u root -pPASS PROCESSLIST。如果有任何东西被切断，请连接到 root (mysql -u root -pPASS) 并发出 SHOW FULL PROCESSLIST;。

从进程列表中，调查使用EXPLAIN 出现几次的查询，以深入了解它。如果他们不使用索引，那就是你的问题之一。

另一种选择可能是转移到Percona server 之类的位置。他们有很多新增功能——冰山一角：xtradb（100% 与 innodb 兼容）和一个慢查询日志，可以为您提供更精细的输出（毫秒）。当然，它也是免费的。关于 MySQL 的所有内容的好读物是他们的博客 - the mysql performance blog。

LBNL – 我只是猜测，但可能只是缺乏资源。 c1.medium 是一个不错的入门级实例（t1.micro 或 m1.small 没有真正的用途 IM*H*O），但这可能还不够。这完全取决于数据库的大小和实际流量。

请随时发表评论，我可以尝试扩展我的答案。

加法 – 我刚刚阅读了另一个答案的 cmets。

您可能希望摆脱 EBS 支持的实例。我认为他们是一个非常糟糕的主意。如果你真的需要持久性，你想创建一个带有临时存储的常规实例，然后附加几个（超过 1 个）EBS 卷到它和RAID 10 across them 以增加 IO/s。

另外，我还没有提到这一点，但听起来你也缺乏对服务器的监控。就个人而言，我们使用Librato silverline，它为我们提供所有实例的近实时生命体征。这也应该有助于缩小存储的潜在问题。

Answer 3

我在这个主题上不是很有经验的用户，但是当我遇到一些套接字文件问题时，我将我的应用程序配置为使用 TCP/IP。您可以在软件配置中使用 127.0.0.1 而不是 localhost，以强制使用 TCP/IP 而不是套接字文件。

您可能对腾晓峰回复another stackoverflow question 感兴趣：

除了迈克尔的话，

还有一个链接： http://dev.mysql.com/doc/refman/5.1/en/connecting.html，上面写着：

在 Unix 上，MySQL 程序特别对待主机名 localhost，在 与其他方式相比，这可能与您期望的方式不同 基于网络的程序。对于到 localhost、MySQL 程序的连接 尝试使用 Unix 套接字文件连接到本地服务器。 即使给出 --port 或 -P 选项来指定端口，也会发生这种情况 号码。

这不是典型的 tcp/ip 连接。

这当然不会回答你的问题，但也许能解决你的问题。