MySQL cannot create a new binary or relay log file because every candidate name from 1-999 already exists or is unwritable.
MySQL Error 1098: ER_NO_UNIQUE_LOGFILE appears when the server fails to create a new binary or relay log because every candidate file name already exists or cannot be written. Remove or rename stale log files, free disk space, or set a unique --log-bin or --relay-log basename to resolve it.
Can't generate a unique log-filename %s.(1-999)
Error 1098 with condition name ER_NO_UNIQUE_LOGFILE is raised when MySQL tries to create a binary log (or relay log) file but cannot find a unique filename in the 1-999 suffix range.
The server aborts the operation and replication may stop.
The message usually appears at server startup, during replication initialisation, or after FLUSH LOGS when the configured log basename already has numbered files occupying every suffix.
Replication breaks if MySQL cannot rotate or initialise its logs. Backups that rely on binary logging also fail. Ignoring the error risks data loss, delayed replicas, and increased recovery time.
Filename collisions are the primary cause.
MySQL appends .000001-.000999 to the --log-bin or --relay-log basename. If every candidate file exists, the server stops.
Insufficient permissions, full disk, or read-only filesystems prevent MySQL from deleting or creating logs, triggering the same error.
Misconfigured Docker volumes, stale relay logs after server re-clones, or incorrect custom paths also lead to collisions.
First, identify unused or orphaned log files. Rename or purge them so at least one suffix is free.
Ensure the MySQL operating system user owns the directory.
Next, restart the server or issue FLUSH LOGS. MySQL will create the next available file once a gap exists.
If cleanup is impossible, change the basename with --log-bin=mysqllog or --relay-log=relay to force a new numbering sequence.
On a replica that was copied via rsync, leftover master relay logs often collide.
Remove relay-log.* before starting mysqld.
Inside a container where /var/lib/mysql is persistent but configuration resets, each fresh container instance can reuse the same basename. Mount a unique subfolder or adjust the basename per replica.
Automate PURGE BINARY LOGS TO or PURGE BINARY LOGS BEFORE to keep file counts low. Monitor the number of files with SHOW BINARY LOGS.
Always set unique basenames that incorporate the hostname or instance id: --log-bin=binlog_$HOSTNAME.
Galaxy users can store these settings in versioned scripts for team visibility.
Error 1201 (HY000): Could not find end of relay log - occurs when a relay log is truncated; fix by running RESET SLAVE.
Error 1594 (HY000): Relay log read failure - often follows ER_NO_UNIQUE_LOGFILE if lingering files are corrupt; resync replication.
.
RESET MASTER deletes all binary logs and restarts numbering, so it resolves filename collisions on a primary but removes point-in-time recovery history.
Yes, on stopped replicas. Stop the replica, remove relay-log* files and the index, then start replication so MySQL recreates them.
Galaxy stores versioned server configuration scripts and SQL snippets, letting teams document correct log settings and automate PURGE commands, reducing risk of filename collisions.
The mysqld OS user must have read, write, and execute permissions on the directory and files. Use chown mysql:mysql /path and chmod 750 /path.
.avif)
.avif){kind=logo}
