<b>安全专家讲授 Mysql数据库弊端诊断历程</b>[MySQL防范]

那天因参与MS的新品公布大会,正午就离创办公室,当我正在出租车上前往会场的途中,同事打电话来说主数据库呈现写保护错误.这可不得了,全部的利用都靠这个数据库呀,我心里默念:千万不要出漏子,不然就不能参会了!于是我在电话里交代同事重启mysql数据库试试,还好,重启后问题办理.

一散会,就赶忙上去找弊端缘由.这里先描写一下平台环境,把逻辑关系弄清楚.在这个利用中,由一个web前段服务器,一个tomcat利用服务器及一个mysql服务器构成,全部的系统都是linux.用户的恳求先到前端的apache服务器,假如恳求页面是.jsp,apache就把恳求转交给tomcat服务器,tomcat再从数据库获得数据或向数据库插入记录.这是典型的3层利用逻辑.

登录到数据库mysql服务器,用mysql客户端衔接mysql数据库,履行号令 mysql > show processlist; 没发现什么非常,负载也很低.看来从这里看不出什么名堂.接下来当然该看mysql错误日记,发现以下非常:

这个报错的粗心是:内存基本耗尽,没有再可以分配的空间.由此判断是什么东西产生宏大的负荷招致系统内存被榨干了.不过目前数据库服务器已经趋于平稳,暂时查不到什么缘由惹起这个弊端.

基本情形掌握了,停下来歇息半晌,于是顺手收一下邮件,乖乖,来了一封报警邮件,赶忙翻开,其内容以下:

报警消息表明主机61.154.105.100在10:59的这个时间负载过大.而这个主机恰好是tomcat服务器,看来问题就在这个上面.为了近一步确认自己的设法,我来查看一下网络流量:

从流量图可以看出,产生非常流量的时间恰好与报警信息的时间一致,再给同事打电话,问:“你们都在61.154.105.100 这个机械上干了啥?”,答:“履行了一条不精确的sql语句,发现问题后撤消这个sql语句”.至此,缘由查明! 　　以上是“<b>安全专家讲授 Mysql数据库弊端诊断历程</b>[MySQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：