《如何三招搞挂MySQL?》要点:
本文介绍了如何三招搞挂MySQL?,希望对您有用。如果有疑问,可以联系我们。
本文将介绍三种搞挂MySQL的方式,逗大家一乐,同时也会揭露一些MySQL使用过程中的注意事项和实现原理,以供参考.感兴趣的同学可以找一个MySQL实例进行测试.我要说的三种方式分别是:
声明: 这里介绍的三种方式可以搞挂目前大多数的线上MySQL实例,请谨慎测试.一切后果,本文作者及本网站概不责任哦.
众所周知,InnoDB是一个支持MVCC的存储引擎,为了支持MVCC,InnoDB需要保存undo日志,以便对用户提供记录的历史版本.如果我们开启一个事务,反复地更新一条记录而不提交,会怎么样呢?将会产生大量的undo日志,使得磁盘空间爆满,导致MySQL不可用.
在innodb现有的实现中,并没有对单个用户或单个连接使用的undo空间进行限制.也就是说,我们只需要反复更新一条记录,而不提交,就会产生大量undo日志.由于我们的事务没有提交,undo日志不能被回收,从而使得磁盘空间被耗尽,最终导致MySQL挂掉.
Jeremy Cole老早就提到过这个问题,不过该问题至今还存在.要进行该项测试,只需要有更新记录的权限即可.测试脚本如下:
测试过程中,可以观察磁盘空间的使用率,一直在上升:
磁盘空间满以后,再执行SQL语句就报错了,错误信息如下:
错误日志如下:
可以看到,虽然MySQL进程还存在,其实服务已经不可用了.事务在执行过程中,会产生undo日志以及binlog日志,占用磁盘空间,如果我们在线上执行一个大事务,就需要留意是否有可能因为undo和binlog导致磁盘空间爆满的情况.为了规避风险,我们还是应该尽可能地避免特别大的事务.
上面的例子并没有真的让MySQL进程挂掉,而且需要对数据库具有写的权限.你可能不服,那么,我们再来看另外一种情况,即定义大量的用户变量.
这种方式将会导致MySQL占用的内存急剧上涨,最后被操作系统kill掉.而且,不再需要有更新记录的权限,只需要有登录数据库的权限即可.
测试脚本如下:
我们不断地定义用户变量,可以通过pidstat观察MySQL占用的内存:
可以看到,MySQL占用的内存越来越大,最后,MySQL进程不在了.通过dmesg可以看到,是由于MySQL占用内存太多,被操作系统kill掉:
上面的例子演示了一个普通用户耗尽资源,导致MySQL被操作系统kill掉的情况.其实,这个问题是完全可以避免的.MySQL支持在创建用户的时候,限制用户使用的资源.
可以限制的资源包括:
每小时的查询次数
每小时的更新次数
每小时的连接次数
同时建立的连接数
使用方式如下所示:
虽然MySQL支持限制用户使用的资源,但是,在实际使用过程中,很少有人会去限制用户使用的资源,甚至很多用户根本不知道MySQL提供了这样的功能,这给”不法分子”有了可乘之机.
可以说,写MySQL的都是一群科学家,并且,MySQL使用如此广泛,遇到MySQL的bug应该不容易.不过,只要是程序就有可能存在bug,所以,遇到MySQL的bug也不是不可能的情况.如果看MySQL的release note,每次的新版本都会修复无数的bug.尤其以新功能的bug居多.
这一节,我们来测试一下MySQL的bug.即在使用grant授权时,如果使用了一个很长的数据库名,将导致MySQL挂掉.之所以选择这个bug,是因为该bug复现起来特别容易了,只需要执行一条SQL语句即可.
如下所示:
很明显,该问题是由于缓冲区溢出导致,这也是我们编程中容易犯的一个错误.这个bug在MySQL 5.7中已经修复,我在5.6.19中进行测试,MySQL立马挂掉,可以说是搞挂MySQL的最快方式.
在本文中,我演示了三种搞挂MySQL的方式,这三种方式的思路不同,涉及到的知识点也不一样.将这三种方式都尝试一遍,可以搞挂正在使用的无数MySQL实例.那么,是不是说MySQL特别脆弱,非常容易被搞挂呢?答案是否定的.MySQL在各互联网公司广泛使用,已经经受住了无数的考验.
本文之所以显得MySQL容易被搞挂,主要还是因为大部分人的使用姿势不当,以及对MySQL的了解不足所导致的.要避免MySQL挂掉,这里有几点建议:
特别大的事务会占用特别多的资源,甚至出现占满磁盘空间的情况,要避免特别大的事务;
限制用户使用的资源,避免不良用户恶意破坏;
紧随社区的脚步,关注社区报告和修复的bug,必要时升级数据库版本,以免遇到已知bug;
新功能一般bug较多,不要上得太快,避免踩到未知bug.
转载请注明本页网址:
http://www.vephp.com/jiaocheng/4528.html