<p>MySQL cannot locate the binary log file referenced by a replication or recovery command.</p>
<p>MySQL Error 1373: ER_UNKNOWN_TARGET_BINLOG occurs when the server cannot find the binary log file named in a START REPLICA UNTIL, CHANGE MASTER TO, or PURGE BINARY LOGS statement. Verify the file name, confirm it exists in mysql-bin.index, and restart replication to resolve the issue.</p>
Target log not found in binlog index
Error 1373 fires when MySQL looks for a specific binary log file but fails to locate it in the server's binlog index. The message reads: Target log not found in binlog index.
The error commonly appears during replication setup, point-in-time recovery, or manual binlog purges that reference a file that has already been deleted or never existed.
The server checks mysql-bin.index for the requested file. If the entry is missing or mistyped, Error 1373 is returned immediately and the replication thread stops.
The condition also arises after automatic log rotation or PURGE BINARY LOGS commands that removed the file while replication still points to it.
First, verify that the binary log file name is spelled exactly as listed in the data directory. If it is missing, identify the closest available log and update the replication coordinates accordingly.
Next, update CHANGE MASTER TO or START REPLICA UNTIL to reference an existing file and position. Finally, restart replication and confirm Seconds_Behind_Master returns a value.
During delayed replication, the SQL thread may stop at a nonexistent log because logs were purged on the primary. Use SHOW BINARY LOGS on the source, pick the earliest available log, and reset the replica.
For point-in-time recovery, restore from the latest backup and apply only the logs that still exist on disk. Do not reference purged logs.
Enable automatic log purging with expire_logs_days or binlog_expire_logs_seconds to keep logs consistent. Always check replica states before purging logs.
With Galaxy's version-controlled SQL editor, keep CHANGE MASTER scripts in a shared Collection so file names remain accurate across environments.
Error 1236: Could not find first log file. It also indicates missing binary logs but occurs during replication I/O thread startup. Fix by pointing to an existing log.
Error 1201: Could not initialize master info structure. This error sometimes follows 1373 if CHANGE MASTER fails repeatedly. Ensure correct host, user, and log file parameters.
A typo in MASTER_LOG_FILE or UNTIL SQL_AFTER_MTS_GAPS prevents MySQL from locating the target file.
BINLOG files referenced by a replica were removed using PURGE BINARY LOGS or automatic expiration.
The index file lost an entry due to disk issues or manual edits, making legitimate logs invisible to the server.
A replica points to a log file that exists on the source but was never transferred or copied to the replica during recovery.
Triggered when the replication I/O thread cannot locate the first required log on the source. Fix by re-syncing to an existing log.
Often follows repeated failures in CHANGE MASTER TO. Correct credentials and log coordinates to resolve.
Occurs when a relay log is missing or corrupt on the replica. Recreate relay logs with RESET SLAVE.
Signals corrupted binary log content. Re-export logs or fall back to the latest clean backup.
Yes, but clear the incorrect coordinates before restarting replication to avoid future failures.
Only as a last resort and while MySQL is offline. Always back up the file first.
It removes old logs automatically, but you must ensure replicas are up to date before the purge occurs.
Galaxy stores CHANGE MASTER scripts in versioned Collections, making it easy to audit and correct log file names across teams.
.avif)
.avif){kind=logo}
