<p>MySQL cannot locate the binary or relay log file it was instructed to purge, halting the PURGE BINARY LOGS or automatic log-rotate operation.</p>
<p>MySQL Error 1612 ER_LOG_PURGE_NO_FILE occurs when MySQL tries to delete a binary or relay log that no longer exists. Re-run PURGE BINARY LOGS with a valid file name or reset the master/replica to realign log indexes.</p>
Being purged log %s was not found
MySQL raises error 1612 with message "Being purged log %s was not found" when it attempts to remove a binary or relay log file that is missing from the file system. The server aborts the purge and reports the error so that you can realign log pointers.
The error surfaces during manual PURGE BINARY LOGS commands, during automatic log rotation triggered by the expire_logs_days or binlog_expire_logs_seconds settings, or while a replica tries to delete relay logs after applying events.
Failing purges leave obsolete log indexes, inflate disk usage, and can break replication if relay-log indexes reference non-existent files. Quick remediation keeps storage in check and maintains replication health.
Common triggers include accidental OS-level deletion of log files, misuse of PURGE BINARY LOGS with the wrong file name, and file-system corruption or backups that move logs. Replicas can also lose logs if relay-log-purge is disabled and files are manually removed.
First, verify which log files actually exist in the datadir. Adjust the log index with RESET MASTER or RESET SLAVE if using replication. Then issue PURGE BINARY LOGS TO 'valid-file'; using the latest file on disk. Restart replication to confirm SQL thread stability.
Galaxy’s context-aware SQL editor warns you when a PURGE BINARY LOGS statement targets a non-existent file by reading the binlog index before execution. Versioned query history also prevents accidental reuse of outdated purge commands.
Enable automatic log expiration, monitor free disk space, and avoid manual OS deletions. Keep relay-log-purge enabled on replicas. Periodically audit the mysql-bin.index and relay-log.info files to confirm they match files on disk.
Someone removed binary or relay log files directly from the file system instead of using PURGE BINARY LOGS, leaving index pointers orphaned.
A PURGE BINARY LOGS TO or BEFORE command specified a log file that never existed or was already purged.
Relay-log.info references a relay log that was lost due to disk cleanup or accidental move, and the replica purge fails.
Hardware or filesystem errors deleted or renamed log files without updating MySQL index files.
Occurs when trying to purge logs while they are still needed by replication peers. Requires adjusting gtid_purged or replica positions.
Alerts that a statement is unsafe for statement-based replication, unrelated to purging but also binlog related.
Replica cannot read a binlog file, often after it was deleted or corrupted, similar root cause of missing files.
No. Ignoring leaves inconsistent log indexes and can break future purges or replication. Always realign indexes or regenerate logs.
Yes. RESET MASTER removes every binary log and resets the index. Be sure to take backups or confirm replicas have applied all events.
Run SHOW BINARY LOGS and copy the exact file name of the newest log you wish to keep. Use that in the PURGE statement.
Automatic expiration reduces manual purges and the risk of missing files, but OS-level deletions can still trigger the error.
.avif)
.avif){kind=logo}
