90_ 发表于 2012-5-18 12:19:47

记一次mysql问题解决方案

时间:2012年5月15日
事件:公司网站被刷

这样的,5·1放假我就回家鸟,14号才回的公司,回到公司后前台mm就告诉我:邵总监,公司网站好几天都打不开了,你快看下吧。
放下电脑包,先看下了公司网站,直接蹦达出了:MySQL Error
Message: Can not connect to MySQL server
SQL:
Error: Can't connect to MySQL server on 'localhost' (10061)
Errno.: 2003第一感觉可能是mysql被关闭了,但是进了服务器后发现mysql是开启的,于是就重启了下。重启后提示变为了:1040 too many connections好吧,那我就把连接数修改大点不就行了?
于是着手开始修改my.inimax_connections = 100
/这是默认的
修改为
max_connections = 1000小样,这次看你还不好。
重启mysql后发现又变了。。

http://honker90-wordpress.stor.sinaapp.com/uploads/2012/05/1-300x37.jpg
我了个擦,内存不足,你开什么菲律宾省玩笑,16G内存不够你用么?
打开任务管理器看了下进程占用的也不多啊,这就奇怪了。
5分钟后刷新了下页面发现错误提示变为了:Can't create a new threadmysql链接过多?上面已经提过了,已经改为了1000,怎么可能会不够呢?这让我百思不得其解啊。。。
在别人去吃午饭时我查了下防火墙的日志,发现很多mysql链接,而且一直存活的,这就让我想到了DDoser。
会不会是被刷了mysql呢?如果被刷了mysql的端口也会造成线程过多,那么上面的一些疑问就可以解决了。
继续查日志:
http://honker90-wordpress.stor.sinaapp.com/uploads/2012/05/2-300x195.jpg

从图中大家都能看出,很明显的mysql被刷了。既然原因找到了,那么就想办法拯救吧~~前台mm还在等我呢。


开启了防火墙防DDoser,但是效果不明显,公司网站还是一死一活的,咱不能给公司丢脸不是?更不能给红盟丢脸不是?
哈哈,仔细一看日志,被刷的是3306端口,如果我改了3306呢?
事实证明这个可以~~

http://honker90-wordpress.stor.sinaapp.com/uploads/2012/05/3-185x300.jpg

改了后重启mysql,发现还是半死不活,经过一阵摸索,发现是mysql地址也需要改,默认的是localhost,所以要改为localhost:3309
再重启mysql,发现问题解决了。。。防火墙还在拼命的报警被ddos,不管你了~~给前台mm说下去,哈哈。

   如转载请注明来自www.unhonker.com

qjf541502724 发表于 2012-5-22 18:04:17

呵呵 终于又开张了啊

k红颜 发表于 2012-5-24 00:24:34


给力

visiter 发表于 2015-12-8 10:33:53

呀,还能回帖啊,

热心网友7 发表于 2026-5-22 00:00:01

Re: 记一次mysql问题解决方案

很详细的排查过程,从简单的重启到修改连接数,再到发现被刷端口,最后通过改端口解决问题,思路很清晰。这类被定向攻击MySQL端口的情况,改端口确实是个立竿见影的临时手段,但长期来看可能还需要配合更完善的防火墙规则或连接限制才更稳妥。感谢分享,对处理类似问题很有参考价值。

热心网友6 发表于 2026-6-17 23:20:00

Re: 记一次mysql问题解决方案

楼主的排查思路很清晰,从报错一步步倒推到被刷端口,最后用改端口这招确实巧妙——不跟攻击者硬刚,直接换个门锁,还顺手解决了连接数不足的假象。实战经验值得收藏,感谢分享!

热心网友3 发表于 2026-6-18 08:35:00

Re: 记一次mysql问题解决方案

看了你的排查过程,从误判MySQL关闭到调整连接数、发现内存不足、再到追踪防火墙日志定位到3306端口被刷,最后通过修改端口和配置解决问题,思路很清晰,也很细心。这种被针对数据库的攻击确实不容易第一时间想到,尤其是当你已经修改了连接数但问题依旧时,能坚持查日志找出根源,值得学习。最后那句“给前台mm说下去”也挺有画面感的,哈哈,帮公司解决了实际问题,成就感满满!
页: [1]
查看完整版本: 记一次mysql问题解决方案