3

情况是，我们有 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

我们想找出问题所在以及如何防止它像那样掉下来。

4

3 回答 3

1

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

如果您不想玩弄新的 mysqlnd 多路复用插件之类的东西（请参阅介绍，请参阅常见问题解答，我建议您wait_timeout显着降低并max_connections在遇到流量高峰时（在 mysqld 端）观看。

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

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

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

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

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

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

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

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

另外——我刚刚阅读了对另一个答案的评论。

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

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

于 2012-09-08T13:46:11.807 回答
1

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

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

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

mysql.allow_persistent = Off

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

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

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

于 2012-09-05T02:53:26.837 回答
1

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

您可能对腾晓峰对另一个 stackoverflow 问题的回答感兴趣：

除了迈克尔的话，

还有另一个链接： http ://dev.mysql.com/doc/refman/5.1/en/connecting.html ，它说：

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

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

当然，这不会回答您的问题，但可能会解决您的问题。

于 2012-09-10T02:59:29.547 回答