记一次mysql故障处理
Posted Jack秦
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次mysql故障处理相关的知识,希望对你有一定的参考价值。
突然间,个人网站崩溃了!相信这个报错作为运维都应该清楚的,是数据库宕机了。
数据库我采用mysql 5.1.63,上机查看错误日志:
171010 10:11:01 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var
171010 10:11:01 InnoDB: Initializing buffer pool, size = 512.0M
171010 10:11:01 InnoDB: Error: cannot allocate 536887296 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 22442704 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
171010 10:12:01InnoDB: Fatal error: cannot allocate the memory for the buffer pool
171010 10:12:01 [ERROR] Plugin \'InnoDB\' init function returned error.
171010 10:12:01 [ERROR] Plugin \'InnoDB\' registration as a STORAGE ENGINE failed.
171010 10:12:01 [ERROR] Unknown/unsupported table type: INNODB
171010 10:12:01 [ERROR] Aborting
171010 10:12:01 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete
171010 10:12:01 mysqld_safe mysqld from pid file /usr/local/mysql/var/qyi-599a87c5e1fa7.pid ended
^C
我以为是innoDB引擎的坏掉了,于是重新编译安装了mysql,后来才发现,原来是配置文件中
innodb_buffer_pool_size 设置的值过大了,(我设置了1G) 呵呵 ,缓冲池过大了,云服务器上的内存不过也就才1G。
查了资料得知原因:
这个报错的大意是,内存基本耗尽,没有再可以分配的内存.
解决办法:查看/etc/my.cnf,找innodb_buffer_pool_size,发现设值已经超过了系统总内存,然后重新设置为系统内存1半,即innodb_buffer_pool_size = 512M 重启MySQL就OK了.
于是我修改my.cnf中参数:
innodb_buffer_pool_size = 512M
尝试启动mysql,结果不尽人意,依然报错上述错误。
于是我方了。。。。。我尝试各种方法,比如说初始化!!!!
一般来说初始化不会对线上数据造成什么影响,但是~!生产环境可千万不要这样操作,万一哪天不幸运,初始化完出故障了,那这个锅你背定了。
按照我的想法继续走。我本人是个菜鸟,写这篇文章可能会被喷,是内存的问题为什么要动数据?
我本人是个喜欢折腾的人,而且这个又是我的云机器所以我当试验机随便折腾了。。好坏都无所谓。所以我这么做,还可以锻炼我对于mysql的理解呢,何乐而不为?
然后、、、初始化过后,我把datadir目录下的数据全都删了!!!!对没错,全删了,或者是移到了其他不重要的目录里面去。
是什么给了我这么大勇气删数据库?当然是binlog日志哈哈哈,我可是对他做了备份呢。诺,你看。之前操作过的数据都会保存在binlog日志中,在其他没有备份机制的情况下通过他可以备份出sql文件,然后导入MySQL。
mysqlbinlog --start-datetime="2017-09-30 16:41:00" --stop-datetime="2017-09-30 20:48:00" mysql-bin.000003 > wordpress.sql
好了,这次备份也有了我重新进到MySQL 的datadir目录重新初始化,初始化完后目录下会有两个目录分别是mysql、test
启动mysql。这时候打开另一个会话窗口查看日志,我的心都要崩溃了。。。
跟上面报错一模一样,最后我没办法了,没脾气了,我直接reboot !!哼哼这次看你还怎么报错。
linux内存管理是非常合理的,是不需要我们插手管理的,他会根据内存大小自动存储到cache里。当然这次的重启就是为了释放内存,有人说我小题大做,手工释放一次内存不就行了?我能告诉你我当时没有想到这一点嘛。。。。看来我考虑的还不够全面啊哈哈,还是欠缺考虑。这次是我的试验机,下次如果是线上的业务机器不让重启那可就没辙了,还有万一重启起不来可就完蛋了。不过一般企业为了数据安全起见,都会部署至少两个或两个以上的数据库,做个主从,以备故障之需。上次线上机器mysql的innodb出现故障,还好只是sdb,于是我果断删除目录重新初始化,然后再从MDB把数据给同步过来恢复了正常。
在Linux系统下,我们一般不需要去释放内存,因为系统已经将内存管理的很好。但是凡事也有例外,有的时候内存会被缓存占用掉,导致系统使用SWAP空间影响性能,此时就需要执行释放内存(清理缓存)的操作了。我可真是傻,百度上有释放内存的资料,我竟然没有想到。哎,这里记录下一下吧。
配置文件/proc/sys/vm/drop_caches。这个文件中记录了缓存释放的参数,默认值为0,也就是不释放缓存。他的值可以为0~3之间的任意数字,代表着不同的含义:
0 – 不释放
1 – 释放页缓存
2 – 释放dentries和inodes
3 – 释放所有缓存
接下来,我们需要将需要的参数写进/proc/sys/vm/drop_caches文件中,比如我们需要释放所有缓存,就输入下面的命令:
#echo 3 > /proc/sys/vm/drop_caches
此指令输入后会立即生效,可以查询现在的可用内存明显的变多了。
要查询当前缓存释放的参数,可以输入下面的指令:
#cat /proc/sys/vm/drop_caches
好了重启ok了,之前做了所有服务开机自启动,发现mysql已经启动成功了,但是数据目录里面没有东西,原因是我刚才把它删了哈哈哈。。。。
所以现在备份的sql文件有作用了!!!
直接导入 mysql < wordpress.sql
大功告成!!!!!我的个人网站又可以访问了。
以上是关于记一次mysql故障处理的主要内容,如果未能解决你的问题,请参考以下文章
记一次MySQL启动故障 Can't connect to local MySQL server through socket