记一次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

大功告成！！！！！我的个人网站又可以访问了。