mysql 跨版本逻辑导入_逻辑导入导致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服务失去连接

NZFNfa.png

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

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

FZFBzu.png

VZVNZ3.png

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

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

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

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

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

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

yY36Rf.png

NVjqAv.png

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

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

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值