记一次mysql故障排除和硬盘扩容

问题发现

某天早上发现我的博客突然不能访问了。简单看了一下可能是数据库连接出了问题。这台服务器比较节约，网站和数据库都放在一个机器上。讲道理不该出现数据库连接问题的。

解决思路

首先需要熟悉mysql各个文件保存位置

项目	位置
日志保存位置	/var/log/mysqld.log
数据保存位置	/var/lib/mysql

通过查看日志可以发现是一个很常见的问题，硬盘满了。顺便如下是查看硬盘使用情况的命令

df -h

如下的/dev/vda1 一度达到了0%可用

[root@ftc-it-portal log]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.7G     0  3.7G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G  656K  3.7G   1% /run
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/vda1        59G   50G  7.0G  88% /

清理空间

删除binlog，删除了一个binlog.00003.因为这个文件很大。同时也需要删除binlog_index中的这个0003。否则也就会报错找不到文件从而无法启动mysql。当然如果是生产环境不建议删除binlog哈，因为大公司所有东西都要留档的。

然后同时我发现，mysql的 log文件也特别大。我暂时清理了一下log文件，这样硬盘至少有几个G可以启动mysql服务了。

清除报警

进一步排查，发现mysql日志中有很多的重复报警如下：

2024-12-16T03:17:40.208208Z 89 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'

可能是因为这个报警，导致日志文件特别大。这是因为我跑在服务器上的一个Wordpress应用。

下面这种方式使用新模式连接mysql，这样可以从根本上解决报警。但是我用的老的NaviCat，就无法连接了。

解决方式，首先，在my.cnf中加入如下配置

default_authentication_plugin=caching_sha2_password

重启mysql后，运行如下语句

ALTER USER 'itdx'@'%' IDENTIFIED WITH caching_sha2_password BY 'Abc@1234';

所以推荐如下方式，也就是在配置文件中加入如下语句即可：

log_error_suppression_list='MY-013360

也可以在设置里加入日志过期时间

expire_logs_days=30

硬盘扩容

同时我在阿里云也进行了硬盘扩容，接下来的问题是，这个扩容的硬盘，要如何应用到系统中去呢？

事前准备，需要安装硬盘扩容工具

yum install cloud-utils-growpart yum install xfsprogs -y

首先，使用growpart命令

[root@ftc-it-portal ~]# growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: size=125827039 end=125829087 new: size=419428319 end=419430367

然后，再使用resize2fs命令

[root@ftc-it-portal ~]# resize2fs /dev/vda1
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 13
The filesystem on /dev/vda1 is now 52428539 blocks long.

最终，确认结果。可以看到/dev/vda1已经是200GB了。

[root@ftc-it-portal ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.7G     0  3.7G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G  512K  3.7G   1% /run
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/vda1       197G   50G  140G  27% /
tmpfs           756M     0  756M   0% /run/user/0

解决根本问题

过了几天我发现硬盘使用空间还在一直增大，通过如下方法，终于找到了罪魁祸首

# 查看硬盘使用情况
df -h# 查看当前目录，最大的文件夹
du -h --max-depth=1# 查看所有文件夹大小
du -sh *

原来是docker的日志文件，竟然有50个G那么大。通过如下方式，清理了日志

# docker中的日志文件清理，/var/lib/docker/containers/b0c9ed5
cat /dev/null > b0c9ed511b7042d75bb9b1aa4bf95f41419f4a202d23dc57482d63a4e58b29b7-json.log

同时重新运行了容器，指定了日志文件大小

docker run -it --name wordpress_new --log-opt max-size=10m --log-opt max-file=3 -p 9898:80 -v /opt/wordpress:/var/www/html -d wordpress

这下问题彻底解决了。

也可以在docker的配置文件/etc/docker/daemon.json中加入如下配置，这样新的容器就默认会限制日志大小了。

{"log-driver": "json-file","log-opts": {"max-size": "10m","max-file": "3"}
}