MySQL cannot write data because the disk or partition holding the data directory is full; the server pauses writes and retries until space is freed.
MySQL Error 35 EE_DISK_FULL_WITH_RETRY_MSG appears when the database server runs out of disk space while writing. Free up disk space, move the data directory, or expand the file system to resolve the error. Clearing binary logs is the fastest fix for most production servers.
Disk is full writing '%s' (OS errno %d - %s). Waiting for someone to free space... Retry in %d secs. Message reprinted in %d secs. EE_DISK_FULL_WITH_RETRY_MSG was added in 8.0.13.
MySQL raises EE_DISK_FULL_WITH_RETRY_MSG when it cannot complete a write operation because the underlying disk or partition is full. The error message includes the file path, operating system error number, and a countdown before the server retries the write.
The error was introduced in MySQL 8.0.13 as a global error to alert administrators that the server will pause writes and periodically reattempt them.
While reads continue, any transaction requiring disk space blocks, impacting application availability.
Resolving the issue quickly is critical because long-running locks can cascade, timeout, or lead to application-level data loss.
Insufficient free space on the data or tmp directory prevents InnoDB from flushing pages, writing redo logs, or creating temporary tables.
Large transactions, runaway binary logs, oversized temp tables, or audit logs commonly trigger the condition.
Misconfigured partitioning can concentrate data growth on a small volume even when other disks have capacity. Similarly, leaving binary or relay logs unpurged consumes space until the partition is full.
Immediately free space by removing or archiving log files, dropping unnecessary temp files, or moving the MySQL data directory to a larger partition.
After space is available, unblocked transactions resume automatically.
In the long term, configure automatic log purging (PURGE BINARY LOGS, expire_logs_days), monitor disk usage, and separate data, log, and temp directories across dedicated volumes to prevent recurrence.
Binary logs grew unchecked on a replication master: use PURGE BINARY LOGS TO 'mysql-bin.012345'; to remove old logs once replicas have applied them.
Large SELECT ...
INTO OUTFILE filled /var/lib/mysql: move outfile_dir to a separate mount or write to a network share.
ALTER TABLE created a full copy of a multi-GB table: enable ALGORITHM=INPLACE or use pt-online-schema-change to avoid a full table copy.
Enable automatic log rotation, set innodb_monitor_enable="all" with monitoring to receive early disk alerts, and allocate at least 20 percent free space on data and temp partitions.
On Galaxy, set up custom alerts that watch disk metrics and binary log size; the collaborative SQL history helps identify exploding queries before they exhaust storage.
ER_DISK_FULL alerts on immediate disk full without retry logic.
ER_TEMP_FILE_WRITE_FAILURE indicates a write failure in the tmp directory. Both resolve through the same free-space or directory-move techniques.
.
Binary or relay logs remain on disk because automatic purging is disabled or replicas lag behind, eventually filling the partition.
Complex queries create on-disk temp tables in the tmpdir; if tmpdir shares the data volume, both compete for space until full.
Huge INSERT or table rebuild operations double storage use temporarily, exhausting capacity on small volumes.
System logs, core dumps, or other application files consume the same partition MySQL uses, reducing available space unexpectedly.
.
The server retries indefinitely at the interval shown in the message until space is available or the server stops.
Yes, SELECT operations that require no new temporary files still run, but writes block until space frees up.
No. Once enough space is available, blocked transactions resume automatically without a restart.
Galaxy surfaces disk metrics in context and lets teams track query growth, enabling proactive cleanup of space-heavy artifacts.
.avif)
.avif){kind=logo}
