问题 EC2 MySQL不断崩溃

要小心你没有足够的内存，是的，这是你看到的错误，但这也是一个症状不是原因。在支付更大的实例之前等待，问题只会消失一段时间，直到内存再次填满。

警惕创建SWAP文件，再次只是包装症状。

也要警惕改变配置设置（以及限制你的apache或mysql的性能），这些设置已经运行了一段时间，但现在突然间，服务器根本不会长时间停留。

想想怎么可能真的是设置？如果在PHP中存在严重优化的设置或内存泄漏，那么在相同的时间段之后它将一直失败。因此，假设您最近没有安装新模块并且在一段时间内拥有相当静态的环境，则不太可能是内存泄漏或设置。 显然，如果你刚刚安装新模块，那么禁用它们应该始终是第一步

要小心将数据库拆分到另一台服务器，这不会像购买更大的服务器解决问题一样解决问题。是的，每个函数最初会获得更多内存但是.....

要小心从apache迁移到另一个http服务器，如NginX，这是一个激烈的步骤，这可能会解决问题......但是由于错误的原因

我对其中的大部分内容感到内疚并提出了许多错误的希望，直到我查看了apache / var / log / httpd / ACCESS_LOG文件并看到我的网站每秒都被同一个IP命中几次，正在寻找一个名为XMLRPC.PHP，某种在Wordpress圈子中众所周知的DDOS攻击。

示例access_log条目....

191.96.249.80 - - [21 / Nov / 2016：20：27：53 +0000]“POST /xmlrpc.php HTTP / 1.0”200 370

每次收到apache都会尝试实例化子进程来为该请求提供服务。不久之后，内存不足，apache开始无法分叉新进程，而mysql放弃尝试将内存空间分配给缓冲池。你基本上没有内存，所有这些请求都会使你的服务器停止运行。

为了解决这个问题，我更改了.htaccess文件以拒绝从该IP访问该文件，我的服务器立即恢复正常运行。

例如.htaccess

<Files xmlrpc.php>

order allow,deny

deny from 191.96.249.80

allow from all

</Files>"

希望我辛苦获得的发现可以帮助别人！

显然，如果您的访问日志没有显示DDOS效果，则可能是其他内容，请尝试以上所有操作！ ;-)但我现在看到几个wordpress / apache网站对这次攻击表示赞赏。 ...也是同样的IP！遗憾的是，亚马逊AWS不允许在其安全组中使用黑名单。 [叹]

错误说明了一切 - 没有足够的内存来保存池。

如果这是一个受小负载影响的测试实例，那么您可以尝试安装小样本cnf

http://fts.ifac.cnr.it/cgi-bin/dwww/usr/share/doc/mysql-server-5.0/examples/my-small.cnf

（官方的一个在MySQL网站的某个地方，我似乎无法找到它）。

否则，出于生产目的，我会认真考虑Mike Brant的解决方案;否则，您需要一个更大的Amazon实例。

我通过调整apache来修复它 - 它通过尝试启动太多备用服务器来耗尽所有内存：

#MinSpareServers    5
#MaxSpareServers   20
MinSpareServers    2
MaxSpareServers   4

当然，您需要一定的金额来运行您的网站，但我的网站流量很低。

继上面的Binthere回答之后，我的EC2实例上的MySQL服务器崩溃也是由于DDOS攻击而与内存耗尽的微实例无关（这也很可能）。根据我在网上找到的一些很棒的链接，以下是我快速检查问题所采取的步骤。

1 - SSH进入实例

2 - sudo tail -200 / var / log / httpd / access_log

然后我在Wordpress XMLRPC文件上看到了来自1个IP地址的很多POST请求。这是攻击。

3 - 如果他们与我联系，他们会向亚马逊滥用团队报告此事的屏幕截图（他们首先采取行动，我已经在给亚马逊打电话后发现）

4 - sudo cp / var / lock / subsys / mysqld / root / mysqld

5 - sudo rm / var / lock / subsys / mysqld

6 - sudo服务httpd停止

7 - sudo service mysqld restart

8 - 在重新启动网络服务器之前，我对/ var / www / html的web根目录中的.htaccess文件进行了一些更改 （这些是针对我的攻击问题） sudo nano /var/www/html.htaccess

订单允许，否认 否认 允许所有人

9 - sudo服务httpd启动

10 - 呼吸缓解的迹象（无论如何我都是这样！）

希望这对任何人都有帮助:)

嗯，这是2016年12月，显然这仍然存在。

一位客户报告说，他的一个网站（不是由我公司管理）关闭并要求提供支持。当我们开始寻找问题时，由于此漏洞，他的网络服务器显然是DDoS。

缓解程序在其他答案中已经涵盖了很多，所以我只想加上我的2美分：此外 .htaccess 规则，您也可以阻止发起请求的IP iptables。看到 这里快速浏览。基本上你从中得到的是：

1. Apache（或您正在使用的任何内容）不会消耗回复的开销资源 403 到攻击来源甚至记录它们（保存 地段 磁盘空间） - 您的机器将忽略请求;

2. 如果您意识到请求来自同一子网，则可以阻止每个子网源的请求，同时攻击许多受到攻击的计算机。

这显然存在无法验证所提请求的有效性的缺陷，但这也是其他解决方案中的一个因素，以及 xmlrpc.php 仍然无法进入。此外，从这些来源请求的任何文件都将被拒绝。

基本上，我 grep'ed要求 xmlrpc.php 被Apache记录并计算出哪些是最令人不快的：

cat  /var/log/apache2/access.log | grep xmlrpc.php | awk '{print $1;}' | sort -n | uniq -c | sort -nr | head -20

这将打印出排名前20位最易受攻击的IP的排序列表。我注意到在我的前5个最常见的攻击者中，有4个来自同一个子网。

然后，在您确定要阻止哪些之后，假设它们具有类似的IP 123.123.123.123：

sudo iptables -A INPUT -s 123.123.123.123 -j DROP

或者，如果要定位某个子网：

sudo iptables -A INPUT -s 123.123.123.123/24 -j DROP

该 /24 表示您正在定位 123.123.123.XXX 其中XXX可以是任何组合。尽可能多地重复此过程。我用几条规则阻止了90％以上的请求，但YMMV。

此外，请注意，这将停止记录那些违规请求，除非您删除 iptables 您在上面设置的规则。

希望这可以帮助！

我的t2.small EC2实例遇到了类似的问题。我会登录并重新启动mysql，在熟悉的数据库错误消息重新出现之前，该网站可以使用大约5分钟。

这是一个运行带有弹性IP的Wordpress网站。按照这些步骤后，我没有丢失任何数据。我知道这是由于此实例上的EBS存储。

脚步：

1. 登录AWS控制台

2. 转到EC2并选择实例

3. 操作 - >实例状态 - >停止（大约需要3分钟停止）

4. 操作 - >实例设置 - >更改实例类型（我从t2.small转到t2.medium）

5. 操作 - >实例状态 - >开始

整个过程几乎没有时间，一旦实例开始我重新加载网站，一切都恢复正常。

在升级您的实例时，显然需要考虑价格。

更多信息： http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html