Which MySQL Files Can Be Safely Deleted When Disk Space Is Low?

Identify the full filesystem

Check which mount point is full and the inode usage, then query MySQL for the actual data, binlog, error‑log and temporary directories:

df -hT
df -i
mysql -NBe "SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('datadir','log_bin_basename','log_error','tmpdir','innodb_tmpdir');"

If df reports a full mount but du shows little usage, look for files that have been deleted but are still held open by the mysqld process: sudo lsof +L1 | rg 'mysqld|mysql' In container environments verify the volume location with Kubernetes commands (replace <namespace> and <mysql-pod-name> with real values):

kubectl -n <namespace> get pod <mysql-pod-name> -o yaml
kubectl -n <namespace> get pvc

Collect file, tablespace and topology information

Do not delete anything yet. List directory sizes and file sizes, then confirm InnoDB status:

du -xhd1 /var/lib/mysql | sort -h
find /var/lib/mysql -xdev -maxdepth 1 -type f -printf '%s %p
' | sort -n
SELECT @read_only, @super_read_only, @log_bin, @binlog_format;
SHOW MASTER STATUS;
SHOW BINARY LOGS;
SHOW REPLICA STATUS\G

For large tables query information_schema.tables for estimated sizes and free space, and inspect INFORMATION_SCHEMA.INNODB_TABLESPACES for tablespace details.

Objects that can be removed vs must not be touched

binlog.* / mysql-bin.* – cannot remove directly. Use PURGE BINARY LOGS after confirming replication and point‑in‑time recovery (PITR). Risk: replica catch‑up or recovery chain breaks.

ibdata1 / ibdata* – never remove. Requires full migration or rebuild. Risk: InnoDB system tablespace corruption.

ib_logfile* (redo files) – never remove. Must follow the controlled process supported by the current MySQL version. Risk: crash recovery or startup failure.

#ib_*.dblwr (doublewrite files) – never remove. Managed by InnoDB. Risk: loss of recovery protection.

*.ibd – cannot remove directly. Drop the table with DROP TABLE or use a controlled migration. Risk: dictionary and tablespace mismatch.

undo_* – never remove. Handled automatically by InnoDB. Risk: transaction and rollback segment damage.

relay‑log.* – cannot remove directly. Use replication management commands. Risk: replica state corruption.

Error/slow/general logs – do not delete directly. Rotate via logrotate or reopen through MySQL configuration. Risk: audit loss or space not released.

ibtmp1 – never delete manually. Indicates temporary table pressure. Risk: running instance damage.

Completed backups – can delete after verifying retention policy, checksum and off‑site copy. Risk: loss of recovery capability.

Binlog cleanup – the most common space consumer

List binlog files and the retention setting:

SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'log_bin_basename';

MySQL 8.0 uses binlog_expire_logs_seconds; older versions use expire_logs_days. Verify that the retained logs satisfy replica and PITR requirements before purging.

Purge up to a specific file: PURGE BINARY LOGS TO 'binlog.000123'; Purge by timestamp (ensure the server time zone matches @@global.time_zone and @@session.time_zone): PURGE BINARY LOGS BEFORE '2026-07-01 00:00:00'; Never delete binlog files with rm; doing so can desynchronise the index file and cause replication or recovery failures.

Error, slow and general logs

Check whether logs are written to files or tables and locate the real paths:

SHOW VARIABLES WHERE Variable_name IN ('log_error','slow_query_log','slow_query_log_file','general_log','general_log_file','log_output');

If log_output is TABLE, the logs reside in mysql.slow_log or mysql.general_log and cannot be truncated. Use the system’s logrotate or service‑managed rotation: archive old logs, let mysqld reopen the file, and verify the new file is being written.

Disable the general log after security and audit approval:

SET GLOBAL general_log = 'OFF';

Table‑space handling

When innodb_file_per_table is enabled, dropping a table releases its .ibd file automatically. With a shared tablespace or older objects, never delete .ibd directly; use DROP TABLE or a controlled migration after confirming business retention rules.

Large‑scale DELETE operations should be broken into small, indexed batches, with checks after each batch for replication lag, lock wait, redo/undo pressure, and application errors.

Temporary tablespace, redo, undo and doublewrite

ibtmp1

grows due to large sorts, unindexed joins, temporary tables or long transactions. It is rebuilt on restart, but restarting a production instance is disruptive and may not solve the root cause. View active InnoDB transactions:

SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY trx_started;

Never kill connections just to “clear undo”; termination rolls back the transaction and can increase I/O.

Emergency handling, verification and long‑term maintenance

When space is critically low, follow this order:

Confirm the full mount point and the type of large files.

Verify recent backups, binlog archiving and the recovery chain.

After confirming a safe range, execute PURGE BINARY LOGS via SQL.

Rotate logs according to existing procedures.

Plan data archiving and table rebuilds.

If needed, expand the volume or migrate non‑data files following platform processes.

Never run commands such as rm -f /var/lib/mysql/*, delete ibdata1, ib_logfile*, .ibd or relay logs without proper checks.

After any operation, validate both the OS and MySQL sides:

df -hT
df -i
sudo lsof +L1 | rg 'mysqld|mysql'
SHOW BINARY LOGS;
SHOW REPLICA STATUS\G
SHOW GLOBAL STATUS LIKE 'Threads_connected';

Acceptance is not merely “disk space freed”; ensure the instance’s read/write paths, error logs, all replicas, backup jobs and critical business paths are healthy. Long‑term alerts should cover capacity, inode usage, binlog growth, long transactions, temporary tables, replication delay and backup‑restore drills. Deleting files should never be used to gamble on data consistency or recoverability.