mysql访问日志满造成linux磁盘空间不足问题系列跟踪解决

                                                               mysql访问日志满造成linux磁盘空间不足问题系列跟踪解决

本文是生产环境实践中问题的来源及处理方法,时间紧张，不断的排查终于发现根本问题并最终整理出解决方案。

1>故障排错的思路，要注意分析现象，由表及里，发现问题的本质。

2>要注意日常故障排查的逻辑推理，一步步推进。

3>解决问题要先有思路，习惯要好，最后要总结。

4>先最小化验证问题。

做任何事都要思路领先！

故障来源: 互联网用户反馈公司的APP登陆失败，发送短信也失败。

一>排查过程

接到消息后于是我们跟踪APP程序后台并未发现明显报错日志。继而登陆系统整个的管理平台,登陆界面提示用户不存在。（由于排查过程非常紧张，当时图片并未保存，所以“用户不存在”是事后还原出的真实现象）。

于是根据系统架构图思考。下图为系统架构图:

综合管理平台登陆失败下意识的想法，综合管理平台的用户数据是存储在mysql中的mysql库中的表中的，怎么会登陆失败呢？于是去登陆mysql数据库查询，但是用navicat连接mysql显示连接不上服务器。于是登陆mysql所在linux服务器用lsof -i:3306检测，竟然mysql已经宕掉了。于是尝试重启mysql,报错如下:

[root@zhfwpt /]# service mysqld start
Redirecting to /bin/systemctl start  mysqld.service
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
[root@zhfwpt /]# systemctl status mysqld.service
● mysqld.service - MySQL Server
  Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
  Active: activating (start-pre) since 三 2018-11-07 18:47:42 CST; 523ms ago
 Process: 245000 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Main PID: 8994 (code=exited, status=2);         : 245018 (mysqld_pre_syst)
  CGroup: /system.slice/mysqld.service
          └─control
            ├─245018 /bin/bash /usr/bin/mysqld_pre_systemd
            └─245037 /usr/bin/python -Es /usr/sbin/semanage fcontext -a -e /var/lib/mysql /var/lib/mysql-keyring

11月 07 18:47:42 zhfwpt systemd[1]: Starting MySQL Server...

并未发现什么有价值的报错（其实此时可以tail -100f /var/log/messages,但是当时并未查看）。经验使然，看了下磁盘空间大小:

可以发现/var挂载点此时已经达到100%了。可是这与mysql宕掉有什么关系呢？突然想到mysql的数据目录文件不就是在/var/lib/msyql下吗？

于是问题基本得到验证。就是由于mysql的数据文件太大-------造成挂载点/var满盘-------造成mysql宕掉-----然后管理平台登陆不了-----然后APP登陆不了（系统架构）。

二>解决过程

首先让mysql能够起来。既然是/var下磁盘满了，那可以先删掉一些尝试性试探验证下？

于是先把/var/lib/mysql/mysql