MySQL磁盘空间不足排查与inode耗尽解决方案

1. 问题现象与初步排查

春节假期结束后的第一个工作日，我像往常一样检查数据库服务器状态时，突然发现MySQL服务虽然正常运行，但所有写入操作都报出"Disk full"错误。这让我瞬间警觉起来——毕竟磁盘空间不足是数据库运维中最危险的状况之一。

我立即执行了df -lh命令查看磁盘使用情况，结果却显示挂载点/var/lib/mysql所在分区仍有30%的剩余空间。这种矛盾现象让我意识到遇到了一个典型的"伪磁盘满"问题。作为DBA，这种情况需要立即处理，否则可能导致业务数据丢失。

注意：当MySQL报磁盘满错误但系统显示空间充足时，千万不要直接重启服务。这可能导致未完成的写入操作丢失，应先排查根本原因。

2. 深层原因解析

2.1 inode耗尽导致的"伪空间充足"

进一步执行df -i命令后，真相大白——该分区的inode使用率达到了100%。Linux系统中每个文件都需要占用一个inode，当inode耗尽时，即使实际磁盘空间充足，系统也无法创建新文件。这正是MySQL无法写入的根本原因。

bash复制# 查看inode使用情况的关键命令
df -i /var/lib/mysql
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda1      1.2M   1.2M   0   100% /var/lib/mysql

2.2 MySQL的inode消耗特点

MySQL数据库运行时会产生多种类型的文件，每种都会消耗inode：

• 表结构文件（.frm）
• InnoDB表空间文件（.ibd）
• 日志文件（ib_logfile*）
• 临时文件（#sql*）
• 二进制日志（mysql-bin.*）

特别是当数据库中存在大量小表，或者频繁执行产生临时表的复杂查询时，inode消耗会急剧增加。我们的监控显示，春节期间批量数据处理任务创建了数十万个临时表文件。

3. 紧急处理方案

3.1 立即释放inode空间

面对inode耗尽的情况，我采取了以下应急措施：

1. 清理MySQL临时文件：

bash复制# 安全删除MySQL临时文件
find /var/lib/mysql -name "#sql*" -exec rm -f {} \;

2. 归档旧二进制日志：

bash复制# 保留最近7天的binlog
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

3. 优化表结构：

sql复制-- 合并碎片化的小表
ALTER TABLE small_table1, small_table2 
ENGINE=InnoDB ROW_FORMAT=COMPRESSED;

3.2 验证恢复效果

执行上述操作后，inode使用率从100%降至65%，MySQL写入功能立即恢复正常。通过以下命令确认：

bash复制# 检查当前inode使用率
watch -n 1 'df -i /var/lib/mysql'

# 验证MySQL写入能力
mysql -e "CREATE TEMPORARY TABLE test.tmp_test (id INT); DROP TABLE test.tmp_test;"

4. 根因分析与长期解决方案

4.1 文件系统规划不当

原系统配置存在明显缺陷：

• /var/lib/mysql所在分区inode总数仅1.2M个
• 默认的ext4文件系统inode密度不足（每16KB分配一个inode）
• 未针对数据库工作负载特点优化

4.2 推荐的存储配置方案

对于MySQL数据库服务器，建议采用以下配置：

1. 专用文件系统：

bash复制# 创建XFS文件系统（inode动态分配）
mkfs.xfs -f -i size=512 -n size=8192 /dev/sdb1

2. 挂载参数优化：

bash复制# /etc/fstab 配置示例
/dev/sdb1  /mysql_data  xfs  noatime,nodiratime,logbsize=256k,logbufs=8  0 0

3. MySQL配置调整：

ini复制[mysqld]
# 减少临时文件产生
tmp_table_size = 64M
max_heap_table_size = 64M
# 控制binlog数量
expire_logs_days = 7
binlog_format = ROW

5. 监控与预防措施

5.1 关键监控指标

建立完善的监控体系，重点关注：

• inode使用率（阈值建议≤80%）
• 临时文件数量
• 活跃表数量
• 二进制日志增长速度

示例Prometheus监控规则：

yaml复制- alert: HighInodeUsage
  expr: 100 * (node_filesystem_files_free{device="/dev/sdb1"} / node_filesystem_files{device="/dev/sdb1"}) < 20
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Inode usage high on {{ $labels.mountpoint }}"

5.2 自动化维护脚本

设置定期维护任务：

bash复制#!/bin/bash
# 每周清理旧临时文件
find /var/lib/mysql -name "#sql*" -mtime +1 -delete

# 每月优化碎片化表
mysql -e "SELECT CONCAT('OPTIMIZE TABLE ', table_schema, '.', table_name, ';') 
FROM information_schema.TABLES 
WHERE DATA_FREE/power(1024,3) > 1 INTO OUTFILE '/tmp/optimize_tables.sql'"

mysql < /tmp/optimize_tables.sql

6. 经验总结与避坑指南

在实际处理过程中，我总结了以下关键经验：

1. 不要依赖单一指标：

   • 常规监控必须同时包含df -h和df -i
   • 建议将df -i纳入Zabbix/Prometheus基础监控

2. 临时文件处理技巧：

   • MySQL临时文件通常位于/tmp或/var/tmp
   • 可通过tmpdir参数指定专用临时目录
   • 对临时目录使用内存文件系统（tmpfs）可避免inode问题

3. 文件系统选型建议：

   • 对于频繁创建/删除小文件的场景，优先选择XFS
   • 避免在数据库服务器使用Btrfs等COW文件系统

4. 表设计最佳实践：

   • 合并相关的小表为大表
   • 使用分区表替代多个物理表
   • 避免过度使用MEMORY引擎

这次故障让我深刻认识到，数据库运维不能只看表面指标。一个成熟的DBA应该建立立体化的监控体系，同时理解存储系统的底层原理。特别是在节后业务高峰期，更要提前检查系统资源余量，防患于未然。