标签：
这次网站的故障出现的比较突然，没有任何防备，有种突如其来的感觉。这是一台阿里云服务器，采用wdcp的nginx+apache+mysql的方式运行。一位同事在对web目录进行压缩后，由于web目录有很多图片，导致压缩包很大。如果全部压缩的话在4G左右，如果在龟速的网络下，全部压缩下载是个非常痛苦的事情。由于是在wdcp的管理界面中进行的压缩，点击全部压缩后整个web应用都没反应，过了一会干脆直接访问不了。由于web访问页面无法打开，wdcp也访问不了，于是尝试直接用SecureCRT连服务器。可喜的是SecureCRT可以连上服务器。于是有了下面一系列的操作。
1、查看nginx服务是否启动
ps -ef|grep nginx
发现nginx服务没有起来，于是启动nginx服务
service ngxind restart
查看nginx是否启动成功
ps -ef|grep nginx
此时，nginx已经成功启动
root 1690 1 0 12:01 ? 00:00:00 nginx: master process /www/wdlinux/nginx/sbin/nginx -c /www/wdlinux/nginx/conf/nginx.conf www 1692 1690 0 12:01 ? 00:00:00 nginx: worker process www 1693 1690 0 12:01 ? 00:00:00 nginx: worker process www 1694 1690 0 12:01 ? 00:00:00 nginx: worker process
此时刷新网页，仍然无法访问
2、检查apache是否正常
ps -ef|grep httpd
发现apache没有起来，于是启动apache
service httpd restart
查看启动结果
ps -ef|grep httpd root 1716 1 0 12:01 ? 00:00:00 /www/wdlinux/apache/bin/httpd www 1721 1716 0 12:01 ? 00:00:09 /www/wdlinux/apache/bin/httpd www 1722 1716 0 12:01 ? 00:00:11 /www/wdlinux/apache/bin/httpd www 1723 1716 0 12:01 ? 00:00:10 /www/wdlinux/apache/bin/httpd www 1724 1716 0 12:01 ? 00:00:09 /www/wdlinux/apache/bin/httpd www 1725 1716 0 12:01 ? 00:00:11 /www/wdlinux/apache/bin/httpd root 2216 1 0 12:03 ? 00:00:00 /www/wdlinux/wdapache/bin/httpd wdcpu 2228 2216 0 12:03 ? 00:00:00 /www/wdlinux/wdapache/bin/httpd www 2720 1716 0 12:09 ? 00:00:11 /www/wdlinux/apache/bin/httpd wdcpu 2889 2216 0 13:42 ? 00:00:00 /www/wdlinux/wdapache/bin/httpd
再次刷新页面，此时报一个莫名其妙的异常，说文件不存在。由于涉及到具体网站和文件，这里就不贴详细异常了。
于是看看这些文件是否真的少了，然而查找的结果是文件一个都没少。于是发呆了一会，感觉没道理。怎么会报这样的异常呢？郁闷中。。。
又过了一会，看了异常的一个文件，报错的都是一些数据库变量。想了下，这是一个ecshop的程序，会不会是缓存被破坏了的原因呢？于是到将缓存目录的内容都删掉
rm -rf ./temp/static_caches rm -rf ./temp/caches
注意，这里用到了rm -rf，目录开头是“./”而不是“/”，不要自己坑自己了；到时候出问题了呼天喊地，再大声的“我爸是李刚”也没用。
再次刷新页面，此时出现一个异常是
ECSHOP info: Can‘t Connect MySQL Server(localhost:XXXX)!
3、启动mysql
service mysqld restart
执行了上述命令后，等了很久都没反应，心急如焚
MySQL manager or server PID file could not be found!
Starting MySQL.............................................................................................................................
于是ctr + c 结束掉；再次运行，仍然如此。于是看看进程在不在
ps -ef|grep mysqld
发现进程是在的，但就是重启不成功。于是网上查了下，各种说法和原因都有。也有说是mysql目录权限的问题，于是
chown -R root:root /www/wdlinux/mysql-5.1.63
再次检查，仍旧没有解决。有些说kill掉进程重启就行了，但这并不是我原因做的事情。因为kill掉进程是有风险的。后来又折腾了很久，实在没办法，最后还是选择了将进程kill掉。
查看进程ID
ps aux |grep mysql*
将进程kill掉
kill 23238
再次查看，进程还在。。。。。，没办法，只能使出必杀技了（总是隐约中感觉到有点不太好）。
kill -9 23238
再次查看，这会好了，消腾了（好戏还在后头）。
service mysqld restart
期待的是
service mysqld restart
Starting MySQL... SUCCESS!
但是现实总是残酷的，
service mysqld restart ERROR! MySQL manager or server PID file could not be found! Starting MySQL. ERROR! Manager of pid-file quit without updating file.
于是网上找了一下，有说是磁盘空间已满、mysql使用的端口已经被占用、binlog日志文件错误、权限问题等等；还有说要删除日志文件data/mysql-bin.index的，再怎么说不能删日志文件呀，磁盘空间也足够，mysql端口也正常。剩下的就是权限问题了
chown -R root:root /www/wdlinux/mysql-5.1.63
再次尝试启动mysql，仍然无果。于是查看了下mysql的var目录，有一个XXXXXXXXX.err的文件，打开看一下
tail -100 XXXXXXX.err
末尾的一段是这样的
150708 12:04:40 mysqld_safe Starting mysqld daemon with databases from /www/wdlinux/mysql-5.1.63/var /www/wdlinux/mysql-5.1.63/libexec/mysqld: Can‘t find file: ‘./mysql/plugin.frm‘ (errno: 13) 150708 12:04:40 [ERROR] Can‘t open the mysql.plugin table. Please run mysql_upgrade to create it. 150708 12:04:40 [ERROR] /www/wdlinux/mysql-5.1.63/libexec/mysqld: Can‘t create/write to file ‘/www/wdlinux/mysql-5.1.63/var/XXXXXXXXXXXX.pid‘ (Errcode: 13) 150708 12:04:40 [ERROR] Can‘t start server: can‘t create PID file: Permission denied 150708 12:04:40 mysqld_safe mysqld from pid file /www/wdlinux/mysql-5.1.63/var/XXXXXXXXXXXX.pid ended
Can‘t start server: can‘t create PID file: Permission denied，异常仍然说是权限不足。于是
chown -R mysql:mysql /www/wdlinux/mysql-5.1.63/*
再次重启
[root@XXXXXXXXXXXXXXXXX mysql-5.1.63]# service mysqld restart ERROR! MySQL manager or server PID file could not be found! Starting MySQL... SUCCESS!
我的奥特曼终于出现了，于是刷新下网站页面。一切正常，松了口气。。。
4、后记
虽然问题解决了，但是中间还是有很多问题值得思考的。
a、当碰到这样的问题的时候，其实并没有事先想好一个预案和解决办法，碰到问题马上上来就着手解决。只是脑子里有个大概的思路，问题应该出在哪，然后一步步去解决。这也是解决问题的一种方法，但显然不是最有效和快速的。例如，中间的删除缓存，这一步其实就没什么必要了，因为问题不出在缓存，而处在mysql上。
b、对于kill -9和rm -rf这种强有力的杀伤性武器，用的时候必须慎重。如果一不小心kill -9导致整个mysql都用不了呢？想想都觉得可怕，还好这次顺利地解决了问题。
c、wdcp中mysql的var目录需要mysql用户及用户组的权限，也就是说上诉修改mysql目录权限的步骤没有必要。因为这是在没有明确问题所在，又引入了一个新的问题，进而重复解决。说得明白一点就是将简单的问题复杂化了。
d、对于一些占用资源的操作，建议还是直接用SecureCRT等工具操作较为妥当，避免出现不必要的问题。
e、上诉的所有操作也许敌不过一条命令，那就是reboot；据说reboot可以解决掉百分之九十的问题。
f、最后的最后，为什么使用wdcp控制面板压缩会导致这样的问题呢？原因是什么呢？是由于太占用资源导致整个web应用都崩溃掉还是什么原因呢？如果您知道问题所在，请告诉我。
标签：
原文地址：http://www.cnblogs.com/rwxwsblog/p/4630368.html
