<p>The server refuses to purge a binary or relay log because it is still referenced by replication, backup, or recovery threads.</p>
<p>MySQL Error 1378 ER_LOG_IN_USE occurs when you try to purge binary or relay logs that an active replication or backup thread is still reading. Stop or advance the consuming process, flush logs, and rerun PURGE BINARY LOGS to clear the message.</p>
A purgeable log is in use, will not purge
The message "A purgeable log is in use, will not purge" means MySQL detected that a binary or relay log file marked for deletion is still being read by another thread. To protect data consistency, the server blocks the PURGE BINARY LOGS operation and raises Error 1378.
Error 1378 appears in MySQL 5.x, 8.x, Percona Server, and MariaDB when binary logging or replication is enabled. It typically surfaces during manual log purges, log rotation scripts, or automated cleanup tasks.
The most common trigger is an active replica whose Exec_Master_Log_Pos or Relay_Log_Pos still points to the file you want to delete. Backup utilities such as mysqldump or mysqlbackup can also hold file handles open.
Long-running transactions or recovery threads that reference an old binary log may delay purging. Misconfigured GTID or delayed slave settings can keep positions from advancing.
Identify which thread is using the log. Query performance_schema tables or SHOW PROCESSLIST to locate replication, backup, or recovery threads holding the file handle.
Stop or pause the consuming process, or allow replicas to catch up. Once the reading thread releases the log, run FLUSH BINARY LOGS to create a new file and issue PURGE BINARY LOGS TO 'binlog.000XYZ'.
During replica lag: wait until Seconds_Behind_Master is near zero, then purge. For delayed replicas, set MASTER_DELAY to 0 temporarily.
During backup: ensure your backup job completes or use remote backup options that do not lock the file handle. Rotate logs after backups finish.
Automate log purging with mysqlbinlogexpirelogs or expire_logs_days to let MySQL handle safe deletion. Monitor replica lag to avoid purging logs still in use.
Implement Galaxy collections for purge commands and endorse vetted maintenance scripts so teams run consistent, safe operations without manual mistakes.
Error 1221 ER_UNKNOWN_ERROR_IN_ENGINE may appear if the replication thread crashes while reading a log. Restart the replica thread and purge again.
Error 1595 ER_SLAVE_CRASHED – fix by restarting the replica and resyncing from a fresh backup.
A replica is still reading the binary log file, preventing deletion.
mysqldump, mysqlbackup, or XtraBackup keeps the log open during a hot backup.
A transaction started before log rotation keeps a reference to the old log file.
MASTER_DELAY setting intentionally lags the replica, extending log retention.
Raised when the server hits file descriptor limits during purge.
General engine error while deleting log files; often permissions related.
Indicates the replica SQL thread crashed, usually due to corrupted logs.
Occurs when issuing START REPLICA and the replica was already stopped or crashed.
No. MySQL blocks the purge to protect data integrity. Your data remains safe.
Never delete binary logs manually. You risk replication failure and data loss.
Check SHOW PROCESSLIST on the primary or performance_schema tables to see which I/O thread references the file.
Yes, MySQL waits until no thread is using the file before automatic deletion, avoiding Error 1378 in most cases.
.avif)
.avif){kind=logo}
