逻辑导入导致MySQL崩溃案例

主机环境

OS:CentOS6.8

OS内存:7G

MySQL版本:5.7.22

innodb_buffer_pool:6G


最近发现MySQL测试库在每天下午5点左右会莫名崩溃,排查问题发现崩溃时间前后有一个定时任务在执行,这个定时任务会在每天下午4点半执行逻辑导入;将定时任务改到凌晨执行后,第二天早晨上班发现数据库又崩了。

由于error.log不会有任何有用的报错信息,因此这次结合系统日志/var/log/messages来进行问题的复现

开始执行逻辑导入

mysql -uroot -p"密码" xxxxx < /data/wp/xxxxx.2018-09-27.sql

打开top可以看到在几分钟之后,mysqld进程的内存使用率开始飙升,最终突破91%后mysqld进程消失在top显示列表中

导入界面显示已经与MySQL服务失去连接

从系统日志来看,这就是因为逻辑导入引起的oom事件(系统日志显示如下)

由于我是没设置swap的,如果有swap的话,或许能撑一下

逻辑导入导致MySQL崩溃案例_第1张图片
逻辑导入导致MySQL崩溃案例_第2张图片

参考网上的方法,一共进行了2种尝试

第一种是在导入语句中加入参数-q,据说可以不产生缓存

mysql -uroot -p"密码" -q xxxxx < /data/wp/xxxxx.2018-09-27.sql

然而经过测试,该方法并没有什么卵用

第二种方法是在修改innodb_open_files这个参数

在配置文件中,这个参数我设置的是65535,实际使用只有几百

逻辑导入导致MySQL崩溃案例_第3张图片
逻辑导入导致MySQL崩溃案例_第4张图片

在cnf配置文件中将该参数由65535调整为2048,之后重启mysql发现初始占用内存的确有不小的改观,从31%下降到12%

然而在多次的导入之后,仍然发生了oom报错

此外open_files这个参数不宜设置得过小


最终的解决方案是调整了innodb_buffer_pool,毕竟对于总内存仅有7G的OS来说将mysql的内存设置到6G实在是有点太大了;这是此次oom事件的深层次原因

而直接的导火索就是此次的逻辑导入,该库日常的使用也就是不到3G的样子而已

你可能感兴趣的:(逻辑导入导致MySQL崩溃案例)