服务器运维笔记

管理了三个Ubuntu服务器，在阿里云中的一个PHP+Apache+MySQL服务器(WordPress site: www.complexlab.academy)最近经常出现 “Error establishing a database connection” 的连接错误。

根据之前的经验，数据库连接出错一般是因为网站的负载过高，在服务器长时间运行的情况下，MySQL服务有较大概率需要重启。因为电脑不在身边，所以只好用APP发送指令去重启服务器。第一天这个问题解决了，也可能没有解决，但没有接到访问失败的通知。

显然，问题没有解决，第二天访问网站的时候出现了同样的错误。于是登录到数据库进行了清理。WordPress一个很鸡肋的地方在于，每一次更新操作都会在数据库中留下记录，久而久之，数据库中的冗余数据越来越多。WordPress自身没有清理数据库的功能，可以借助于插件WP-Sweep，但注意，在清理之前，先备份数据库。8M的数据库清理后只剩3M，因此，我以为MySQL问题解决了。

Too young…作为运维，我竟然没有看日志，没有看系统资源占用…

问题没有解决，在清理完数据库后不久，又出现了数据库的连接错误。SSH进服务器，重启MySQL，打开网站，神奇的事情发生了，不到1分钟，连接出错，还是数据库连接错误。重复几次后，我判断出几种可能：

数据库在清理中产生问题，通常办法是恢复数据库
WordPress产生的负载太高，需要清理掉部分插件
网站遭受攻击

针对第一种可能，我并没有恢复数据库，只是考虑到最有可能受损的表wp-options，在wp-config.php文件中增加一句代码：

define(‘WP_ALLOW_REPAIR’，true)；

打开 http://mysite.com/wp-admin/，并没有出现修复的界面，因此判断只有很小可能是数据库清理产生的问题。

针对第二种，趁着重启数据库后的1-2分钟可访问时间，在网站的后台将几个插件都禁用清除了。但依旧，很短的时间里，数据库连接报错。

只好打开了资源监视器，CPU在很长的时间里，一直高于50%，超过60%后，数据库的连接就很容易出错了，开始对网站流量并没有什么认识，所以虽然看到流量都比较高，但没有往那方面思考。

Top一下发现前十个都是Apache，Apache处理的是http的访问，这种情况很可能是由于访问过多引起的。查看Apache的log文件，发现了奇怪的记录：

联想到在阿里云的管理控制台看到的被攻击记录，其中有利用xmlrpc.php的攻击：

于是，google后，选取了一种比较彻底的解决方案，通过.htaccess将xmlrpc.php文件的访问禁止掉了，重启Apache服务，看到CPU的占用率马上降下来了，数据库连接也恢复正常。

可网站的进出流量还是不正常，难道还有其它的问题没有解决？

查看出入流量，还是http服务占据了绝大部分。于是继续查看Apache的log，发现有大量访问来自rev.cloud.scaleway.com：

查询对应的ip后(nethogs eth1)，发现是通过调用了cloud.scaleway.com的API，可以使用大量的IP去访问同一个站点。由于IP很多，而且并不是同一个IP段，所以限制IP访问并没有意义。查询Linux服务器如何限制指定域名访问某端口(80端口)，修改了防火墙规则(iptables)，也修改了hosts文件，禁止响应*.cloud.scaleway.com的请求。网站的出入流量下降了很多，一般在10-20kbps。至此，这次任务完成了。

简单记录一下，以后的参考价值不大。主要是为了提醒自己：遇到问题，先检查系统状态，查看log，再一步一步去解决。最后，Google大法好，连攻击都喜欢伪装成google…