Fix MySQL “No space left on device” errors

On Unix-like systems, error 28 means No space left on device. The exhausted resource may be data blocks or inodes, and the affected path may be a temporary or log directory rather than the main data directory.

perror 28
df -h
df -i

Read the full MySQL error message for the failing path. Run checks in the same host or container context as MySQL so you inspect the filesystem it actually uses.

Locate the exhausted filesystem

SHOW VARIABLES LIKE 'datadir';
SHOW VARIABLES LIKE 'tmpdir';
SHOW VARIABLES LIKE 'log_error';
SHOW VARIABLES LIKE 'slow_query_log_file';
SHOW BINARY LOGS;

Check the mount containing each relevant path. A nearly empty system disk tells you little about a full data volume or a small /tmp mount.

For a known data directory on a GNU/Linux host:

sudo du -sh /var/lib/mysql/* | sort -rh | head -20
sudo lsof +L1

The second command can identify deleted files still held open by processes, which consume space even though directory listings no longer show them. Large recursive scans can themselves add I/O load.

Recover space through the owning system

Common causes include binary logs, an accidentally persistent general log, large temporary work, and growing undo or data tablespaces.

For binary logs, inspect replication and backup retention requirements before choosing a cutoff. Run SQL in a MySQL client, not a shell:

SHOW BINARY LOGS;
-- Example only: the named file must exist and still be retained.
PURGE BINARY LOGS TO 'mysql-bin.000123';

TO removes files before the named file and retains that file. Replicas being caught up is only one condition: disconnected replicas and point-in-time recovery may still need older logs. Do not remove binary logs with filesystem commands.

For an unwanted general-log capture:

SET GLOBAL general_log = 'OFF';
-- Only if deleting the retained TABLE-output history is intended:
TRUNCATE TABLE mysql.general_log;

This does not clear a general-log file. Rotate or retire file logs through the established logging procedure after preserving necessary evidence. Never truncate an InnoDB data file, undo file, redo log, or a binary log to make room. If the database cannot operate, expanding storage or removing expendable non-database files is usually the safer first step.

Prevent another full disk

Set a binary-log retention policy compatible with recovery needs, for example binlog_expire_logs_seconds=604800 for seven days where that window is appropriate. Coordinate log rotation with MySQL reopening its files. Monitor both free bytes and inodes on the actual data, temporary, and log mounts; the Guance disk integration can collect these measurements.

Archiving old data may help long-term growth. OPTIMIZE TABLE can require substantial temporary space and rebuilding work, so it is not a first response to a full filesystem. A large shared InnoDB tablespace also does not simply shrink when rows are deleted.

After freeing space, confirm writes resume, review errors and failed application transactions, and check replication health. A restart is not automatically necessary. Use engine-appropriate recovery or consistency checks when evidence calls for them; a blanket CHECK TABLE is not a complete validation strategy for an InnoDB incident.

See MySQL's binary log purge rules.