MySQL磁盘空间充足却报满的排查与解决

1. 问题现象与初步排查

节后第一天上班，生产环境突然告警：MySQL服务无法写入数据。运维同事第一时间检查磁盘空间，df -lh命令显示还有30%剩余空间，但MySQL错误日志却持续报错"Disk is full writing"。这种看似矛盾的状况让整个团队陷入困惑。

我接手这个问题后，首先确认了几个关键信息点：

• 服务器操作系统为CentOS 7.9
• MySQL版本为5.7.32社区版
• 数据目录挂载在独立分区/dev/sdb1
• 使用innodb_file_per_table=ON配置
• 最近没有进行过大规模数据迁移或结构变更

2. 磁盘空间充足但无法写入的深层原因

2.1 inode耗尽问题排查

执行df -i命令后发现，数据分区inode使用率已达100%。这是典型的"磁盘有空间但无法写入"场景。MySQL在创建新表或写入临时文件时需要消耗inode，当inode耗尽时即使有剩余空间也会报磁盘满错误。

为什么小文件会耗尽inode？

• 该实例启用了binlog且未定期清理
• 使用了分区表且每天自动创建新分区
• 临时表目录堆积大量未清理的.ibd临时文件
• 监控系统持续生成的小型状态日志

2.2 文件系统预留空间的影响

使用tune2fs -l /dev/sdb1检查发现，ext4文件系统默认保留了5%的空间给root用户。这意味着虽然df显示有30%空间，但实际上普通用户可用的只有25%。当MySQL进程以mysql用户运行时，可能提前触达这个限制。

3. 紧急处理方案实施

3.1 立即释放inode资源

bash复制# 查找占用inode最多的目录
find /var/lib/mysql -xdev -printf '%h\n' | sort | uniq -c | sort -k1 -n

# 清理过期binlog
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

# 删除临时文件
rm -f /tmp/ib* /var/lib/mysql/#sql_*

3.2 调整文件系统预留空间

bash复制# 将预留空间比例降至1%
tune2fs -m 1 /dev/sdb1

# 立即生效无需重启
mount -o remount /var/lib/mysql

4. 长效预防机制建立

4.1 监控策略优化

在现有磁盘空间监控基础上增加inode监控项：

bash复制# 每日检查脚本
INODE_USAGE=$(df -i /var/lib/mysql | awk 'NR==2 {print $5}' | tr -d '%')
[ $INODE_USAGE -gt 80 ] && alert "MySQL inode usage critical: $INODE_USAGE%"

4.2 MySQL配置调优

ini复制# my.cnf 调整
[mysqld]
tmp_table_size=64M
max_heap_table_size=64M
expire_logs_days=7
innodb_autoextend_increment=64

4.3 自动化清理流程

设置cron定时任务：

bash复制0 3 * * * find /var/lib/mysql -name "#sql_*" -mtime +1 -exec rm -f {} \;
0 4 * * * mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"

5. 故障复盘与经验总结

这次事故暴露出几个关键问题：

1. 监控体系不完善，缺失inode使用率监控
2. 文件系统参数采用默认值，未根据业务特点优化
3. 临时文件清理机制缺失
4. 对ext4预留空间机制理解不足

特别注意事项：

• 使用LVM时可以动态扩展inode数量
• XFS文件系统对海量小文件场景更友好
• 云环境中的块存储可能有额外的inode限制
• 某些MySQL操作（如ALTERTABLE）会生成大量临时文件

在后续的服务器规划中，建议：

• 为MySQL单独划分大inode数量的分区
• 选择更适合数据库场景的文件系统
• 建立完整的空间/inode监控告警体系
• 定期演练磁盘满场景的应急处理流程