主页 / dba / 问题 / 46180
Accepted
700 Software
Asked: 2013-07-12 11:31:53 +0800 CST

罕见错误仅持续一秒钟“无法通过套接字'/tmp/mysql.sock' (146) 连接到本地 MySQL 服务器”146=ECONNREFUSED

  • 772

这是在 Solaris 10 上发生的罕见错误，从 Perl 中看到它，其中这一行
DBI->connect(...) or die "Whoops! $DBI::errstr"

输出Whoops! Can't connect to local MySQL server through socket '/tmp/mysql.sock' (146) at something.pl line ...

我确定在我的系统上，146=ECONNREFUSED

这种错误很少发生，但它会持续发生。
在这个设置上它总是一个暂时的问题——只持续一两秒钟。

全局变量max_connections已被排除为问题。

这不会发生在基于 TCP/IP 的连接上。

我正在使用中的[mysqld_safe] log-error选项my.cnf。该日志在启动时输出以下内容：
mysqld started
InnoDB: Started; log sequence number...
[Note] .../libexec/mysqld: ready for connections.
Version: '5.0.27-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
没有其他日志条目，因此这里没有任何内容表明问题。

如果您可以建议更详细的日志记录设置，请告诉我。

您能否列举仅偶尔发生且仅持续一两秒钟的此错误的可能或可能原因？

mysql errors

1 个回答

  1. Best Answer

    生命有许多伟大的奥秘。对于 MySQL DBA，人生最大的谜团之一就是你的问题。12年来一直如此。事实上，我发现了一个错误报告，当 mysqld 的消失mysql.sock是由于尝试在 mysqld 已经运行的情况下启动 mysqld（又名在脚上射击 mysqld）而导致的。

    我在 StackExchange 中多次亲自解决了这种情况：

    谜团与mysql.sock（MySQL Socket 文件）消失有关。一旦发生这种情况，您将无法使用root@localhost. 事实上，表中定义host='localhost'的用户mysql.user都无法连接。TCP/IP 连接仍然可以使用。解决方法是使用 TCP/IP 连接到 mysqld。

    尝试创建用户root@'127.0.0.1'。然后从 mysql 客户端执行以下操作：

    mysql -uroot -p -h127.0.0.1 --protocol=tcp

    恢复的唯一方法mysql.sock是在 mysqld 未运行时重新启动 mysqld。

    您应该确保明确定义mysql.sock文件/etc/my.cnf

    [mysqld]
socket=/var/run/mysqld/mysql.sock

    当然，去创建文件夹

    mkdir /var/run/mysqld
chmod 777 /var/run/mysqld

    试试看 ！！！

    更新 2013-12-06 10:17 EST

    根据您的评论...

    我包含了日志，如果您知道如何增加详细信息，请告诉我

    您使用的是 MySQL 5.0.27，这意味着您使用的是非常旧的 mysqld（带有大量错误）和旧的 InnoDB 存储引擎。可能没有其他可用的详细信息。我还注意到您使用的是源分发而不是 RPM 安装的二进制文件。

    带回mysql.sock就是重启mysqld。这不会发生在我身上。我从来不需要做任何事情。问题持续一秒钟然后消失。

    如果问题只持续一两秒钟，我可以看到发生了什么。当你运行 service mysql start 时，你实际上是在运行 mysqld_safe。在 mysqld_safe 的底部，有一个无限循环。在无限循环中，它调用 mysqld 并等待返回值。mysqld 的某些返回值将使 mysqld_safe 终止（正常关闭，mysqld 无法再次启动的情况）。其他返回值将导致 mysqld_safe 循环并再次尝试 mysqld。

    建议

    您应该升级到 MySQL 5.6 以获得最新版本mysqld的 InnoDB 存储引擎。如果问题仍然存在，至少由于 MySQL 二进制文件质量更好，包袱会减少。这样，您可以排除 mysqld 并寻找其他外部因素。此外，您应该下载 RPM 二进制文件而不是编译源代码，因为 RPM 版本通常有更多优化。

    更新 2013-12-06 10:39 EST

    如果您回头看我答案顶部的两个链接

    您将了解到第一个链接引用 MySQL 4.0.20，第二个链接来自一个错误报告线程，该线程说有问题的版本是 MySQL 3.22.32（MySQL 3 的最终版本是 3.23.58）

    问题mysql.sock已经存在大约 13 年了，原因是踩到了自己的脚（启动 mysqld，即使它正在运行）、内部因素（非常旧的版本或笨重的 MySQL 版本）或一些外部条件（缺乏 RAM 或其他操作系统资源） .

    然后，看起来你找到了一个内部因素。要验证 mysqld 是否正在自我纠正，请运行SHOW GLOBAL VARIABLES LIKE 'uptime';. 如果数字继续增加并且从未重置，那么您可以正确地责怪笨重的 MySQL 二进制文件没有更详细。MySQL AB 可能正在解决一些内部问题，并且可能在二进制文件中留下了一些调试语句或跟踪点

    更新 2013-12-06 11:24 EST

    刚刚查看了mysqld_safe。有代码打印 mysqld 结束和 mysqld 重新启动。如果 mysqld 确实终止了，mysqld_safe 会记录它。如果 mysqld 由 mysqld_safe 重新启动，则新/新的 mysqld 实例将打印出包括版本号在内的日志信息。由于版本号只打印了一次，很明显 mysqld 从未结束，也从未重新启动过。– George Bailey 13 分钟前

    仅供参考，我发现 146 是 ECONNREFUSED，我将其编辑到我的问题中。– George Bailey 11 分钟前

    然后，您似乎发现了内部问题。源代码编译的 MySQL 5.0.27 mysqld 可能只是在内部恢复后打印调试消息。要验证mysqld是否可以启动，只需运行SHOW GLOBAL VARIABLES LIKE 'uptime';. 如果数字没有重置并且只是不断增加，那么 mysqld 正在从内部进行自我纠正。鉴于您正在使用的旧版本和它的编译方式，我不希望 mysqld 本身会更受欢迎。

    您应该查看 mysqld 是否在启用调试的情况下启动。如果没有，请尝试设置调试，my.cnf看看它是否可以更详细地了解其内部结构。我希望这能揭示问题所在。

    • 4

相关问题