MySQL下PID文件丢失的相关错误的解决方法

这篇文章主要介绍了MySQL下PID文件丢失的相关错误的解决方法,具体的提示可能会是"mysql PID file not found and Can’t connect to MySQL through socket mysql.sock",需要的朋友可以参考下

今天同事A找到我，说是Mysql server X的负载很高，查询很慢。他自己捣鼓了一阵未果后，我们一起看了下。

1. [root@redhat var]# uname -a 
2. Linux xxx 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux 
3.  
4. [root@redhat var]# mysql -u root -p -e “select version();” 
5. +------------+ 
6. | version() | 
7. +------------+ 
8. | 5.1.32-log | 
9. +------------+ 

同事A的操作：

A一看mysql server有问题第一反应是重启mysql server，囧!!o(╯□╰)

但是又使用了错误的命令

1. [root@redhat var]# /var/lib/mysql/libexec/mysqld restart ----操作① 
2. 100708 14:43:53 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root! 
3. 100708 14:43:53 [ERROR] Aborting 
4. 100708 14:43:53 [Note] /var/lib/mysql/libexec/mysqld: Shutdown complete 

发现问题后，他又想起来应该是用下面的命令重启

1. [root@redhat var]# service mysql restart ----操作② 
2. MySQL manager or server PID file could not be found! [FAILED] 
3. Starting MySQL...... 

CTRL+C取消

这时候

1. [root@redhat var]# ps aux | grep mysql 

可以看到，系统又启动了一个Mysql进程，但是过一会后，会自动消失，这时候看日志可以发现以下错误：

1. 100708 15:26:52 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use 
2. 100708 15:26:52 [ERROR] Do you already have another mysqld server running on port: 30017 ? 
3. 100708 15:26:52 [ERROR] Aborting 

然后后面我们一起看。

首先我用client工具连接，发现mysql正常。web应用连接数据库也正常只是查询很慢。

其次我在命令下面，连接：

1. [root@redhat var]# mysql -u root -p 

提示：

1. Enter password: 
2. ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) 

这时候同事A提醒我，可以重启服务没关系。囧，o(╯□╰)o，他在建议我重启解决问题。

好吧，如他所愿。于是我先：

1. [root@redhat var]# service mysql stop 
2. MySQL is running but PID file could not be found 

然后去mysql data dir下面查看，果然没有pid file。

这时候我的第一反应是配置文件不对，导致不能正常停止和重启。

由于server是好的，因此我没有急着去比较以前备份的/etc/my.cnf.bak和/etc/my.cnf。

我们先查找负载高的原因。因为命令行下无法进入mysql，在client下使用

复制代码代码如下:

show processlist;

可以看到里面有很多locked的查询，其中等待时间最久的一个是一个select查询，显示正在sending data，然后其余都是locked。

猜想是sending data的线程占用了“所有的分配给mysql的资源”，导致后来的线程全部挂起，由于“查询(线程)是依次执行的”，后面locked的线程一直在等待前面sending data的线程结束。(这一段是猜想的…)

sending data的这个线程U是一个select 查询，这个select对6张表进行了连接(公司的一个实习生提交的一个查询)，其中有两张表的数据量在10w左右，另外有张data表数据量在 1000w左右，另外还有sum(distinct ) ，group by，order by… 可以想象下…不知道要到何年何月这个查询才能执行完。

这个sending data的慢查询的processid为799，当机立断运行

复制代码代码如下:

kill 799

然后再运行

复制代码代码如下:

show processlist;

可以看到前面locked的线程在一个个依次执行，后面还有好多个跟线程U类似的select线程，全部kill掉后，被堵塞的别的正常的几个Update，select，insert操作很快就执行完了。

而后，web应用恢复正常，速度变快。

返回linux命令行，使用

1. [root@redhat var]# top 
2. <shift+m 按内存使用排序> 
3. <1 显示cpu使用情况> 

这时候可以发现server负载恢复正常。

下面解决无法正常关闭重启的情况。

也就是因为前面同事的误操作引起的

1. ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) 
2. 和MySQL manager or server PID file could not be found! [FAILED] 

的错误。

我前面不是怀疑是配置文件里面有什么无法识别的参数选项么。

通过

1. [root@redhat var]# diff /etc/my.cnf /etc/my.cnf.bak 

发现，配置文件没有问题。

#我的server的hostname，mysql pid文件默认名字为hostname.pid，如果没有在/etc/my.cnf里面指定特定和pid filename和pid file path的话，这个文件是跟mysql数据在一起的。

1. [root@redhat var]# diff /etc/my.cnf /etc/my.cnf.bak 

这时候通过

1. #切换到mysql data dir（mysql的数据文件目录下） 
2. #你们的mysql data dir或许跟我的不一样哦，我的是/var/lib/mysql/var/ 
3. [root@redhat var]# cd /var/lib/mysql/var/ 

获取mysql用户运行的mysql进程的 pid，然后导入到hostname.pid文件里面

1. [root@redhat var]# echo `ps aux | grep mysql | grep "user=mysql" | grep -v "grep" | awk '{print $2}'`>> redhat.pid 
2. #注意这里的redhat.pid跟hostname相关，这里是我的hostname.pid 

将文件的属主和属主组改为mysql:mysql

1. [root@redhat var]# chown mysql:mysql redhat.pid 

然后运行

1. [root@redhat var]# mysql -u root -p 

还是会提示：

1. Enter password: 
2. ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) 

1. [root@redhat var]# ls /tmp | grep sock 

果然没有mysql.sock这个文件

但是这时候运行

1. [root@redhat var]# service mysql status 

显示

1. MySQL running (10949) [ OK ] 

恩，pid file文件恢复正常，然后运行

1. [root@redhat var]# service mysql restart 
2. Shutting down MySQL. [ OK ] 
3. Starting MySQL. [ OK ] 

这时候再运行

1. [root@redhat var]# ls /tmp | grep sock 

可以发现重启后，/tmp下有了mysql.sock这个文件。

大家可以搜索下mysql.sock的用途以及使用产生等等。

同事A的 操作① 导致pid 文件丢失， 操作② 导致mysql.sock文件丢失，大家感兴趣可以去vi mysqld脚本和server mysql脚本，然后导致service mysql status/stop/start/restart运行异常，导致命令行下mysql -u root -p登录mysql异常。

That's all.