为何磁盘空间充足时mysqldump仍提示空间不足？

以下是针对你遇到的问题的具体排查和解决步骤：

• 检查临时目录空间
  mysqldump在备份过程中会使用系统临时目录（默认是/tmp）存储中间数据，哪怕你把最终输出写到大磁盘，临时目录空间不足也会触发errno 28。
  先查看临时目录的剩余空间：

  df -h /tmp
  

  如果/tmp空间不够，给mysqldump指定一个位于B虚拟机大磁盘上的临时目录，修改命令如下：

  mysqldump --host=<machine A> --port=3306 --user=<user> --password=<password> --databases <my_database> --hex-blob --master-data=1 --no-autocommit --default-character-set=utf8mb4 --single-transaction --quick --tmpdir=/path/to/your/large/disk/tmp > dumpfile.sql
  

• 确认输出目录的实际可用空间
  虽然B总磁盘有30000GB，但要确认dumpfile.sql所在的挂载点是否真的有足够空间，可能存在磁盘未正确挂载、用户配额限制的情况。
  查看输出目录的磁盘使用情况：

  df -h $(dirname dumpfile.sql)
  

  同时检查当前用户的磁盘配额：

  quota -u $(whoami)
  

• 检查inode是否耗尽
  磁盘空间充足但inode（文件索引节点）耗尽也会导致无法创建或写入文件，查看输出目录的inode使用情况：

  df -i $(dirname dumpfile.sql)
  

  如果inode使用率接近100%，需要清理该目录下的大量小文件；如果是长期问题，可能需要重新格式化文件系统并调整inode分配比例（操作前务必备份数据）。

• 验证文件系统的单文件大小限制
  部分旧文件系统（如ext3）存在单个文件最大大小限制，哪怕磁盘总空间够，单个文件超过限制也会报错。检查当前文件系统支持的最大文件大小：

  tune2fs -l /dev/your-disk-partition | grep 'Max file size'
  

  如果限制小于备份文件的预期大小，建议将文件系统升级为ext4、XFS等支持大文件的类型。

• 排查数据异常膨胀或网络问题
  先估算数据库的实际大小，对比备份文件的增长速度，确认是否存在数据异常膨胀：
  在虚拟机A的MySQL中执行：

  SELECT table_schema AS 'Database', SUM(data_length + index_length)/1024/1024/1024 AS 'Size (GB)' 
  FROM information_schema.TABLES 
  WHERE table_schema = '<my_database>' 
  GROUP BY table_schema;
  

  如果备份文件增长远快于数据库实际大小，需要检查数据库是否有异常写入（比如大量临时数据插入），或者mysqldump参数是否导致冗余数据生成。

内容的提问来源于stack exchange，提问作者CClarke