MySQL warns that a requested binary or relay log could not be purged because it is the file the server is currently writing to.
ER_WARN_PURGE_LOG_IS_ACTIVE (MySQL error 1868) means the PURGE command tried to remove the current active binary or relay log. Check the active log with SHOW MASTER STATUS and purge only older files to resolve the warning.
ER_WARN_PURGE_LOG_IS_ACTIVE
MySQL returns warning 1868 with message "file %s was not purged because it is the active log file" when a PURGE BINARY LOGS or PURGE RELAY LOGS statement names the file currently being written.
The server skips that file, completes the purge on older logs, and issues SQLSTATE HY000 so administrators know why the target file remained.
The newest binary or relay log is always open for writes. Any attempt to purge this active file conflicts with replication and durability guarantees, so MySQL blocks the deletion and raises the warning.
Automated rotation jobs that rely solely on timestamps or hard-coded filenames frequently select the active log by mistake, triggering error 1868.
Locate the active log first. On a primary server run SHOW MASTER STATUS; on a replica run SHOW SLAVE STATUS or SHOW REPLICA STATUS. The File column shows the current log name.
Issue a PURGE BINARY LOGS TO 'mysql-bin.000123' command using the file just before the active one, or use PURGE BINARY LOGS BEFORE 'YYYY-MM-DD hh:mm:ss' with a safe timestamp.
Manual cleanup - An admin copies the wrong filename. Re-run SHOW MASTER STATUS and purge only earlier files.
Cron job rotation - A script purges by date at midnight. Add a pre-check that compares the file list and excludes the last entry.
Embed SHOW MASTER STATUS in every rotation routine, dynamically building the PURGE statement so the active log is never referenced.
From MySQL 8.0, set binlog_expire_logs_seconds to let the server auto-expire logs, eliminating manual purges and the associated warnings.
Error 1526 ER_BINLOG_PURGE_PROC_LOG closed - Occurs when the named log does not exist. Verify SHOW BINARY LOGS output.
Error 1372 ER_BINLOG_PURGE_EMFILE - Too many open files during purge. Raise the operating system file-descriptor limit or close idle sessions.
Administrators manually specify the highest numbered binlog without checking server status.
Scripts purge all logs older than a threshold that overlaps the active log's creation timestamp.
On replicas, relay log rotation that ignores Relay_Master_Log_File purges the file still needed for replay.
The requested log file does not exist. Validate filenames with SHOW BINARY LOGS before issuing PURGE.
The server reached its open file limit while purging. Increase ulimit or open_files_limit to resolve.
An internal purge failure stopped log deletion. Check error log for details and restart the purge after correction.
It is only a warning. The purge proceeds for eligible files and the server continues running normally.
Ignoring it is generally safe, but repeated warnings signal that your rotation script targets the wrong file and should be fixed.
Galaxy's context-aware editor lets you embed SHOW MASTER STATUS in snippets, preview results, and generate correct PURGE commands, reducing human error.
Yes. When configured, MySQL automatically removes expired logs without needing PURGE BINARY LOGS commands.
.avif)
.avif){kind=logo}
