🚨 MySQL Error Guide: 'ERROR 1236 (HY000)' Got Fatal Error 1236 From Source When Reading Binlog

Exact Error Message

Last_IO_Error: Got fatal error 1236 from source when reading data from binary log:
'Could not find first log file name in binary log index on source'

A GTID-based variant reports missing transactions the source has already purged:

Last_IO_Error: Got fatal error 1236 from source when reading data from binary log:
'Cannot replicate because the source purged required binary logs.'

What the Error Means

ERROR 1236 is raised on the replica’s I/O thread when it asks the source (master) for binary-log events and the source cannot provide them. The replica tracks where it left off — either a binlog file + position, or a GTID set — and requests the next events. If the source has purged, rotated away, renamed, or corrupted the binlog the replica needs, or if the requested position does not exist, the source returns fatal error 1236 and the replica’s I/O thread stops.

Replication halts: the SQL thread may keep applying already-fetched events, but no new events arrive. The data on the replica falls behind and will not catch up until the replica is repointed to a position the source still has, or re-seeded.

Common Causes

• The source purged binary logs (via expire_logs_days/binlog_expire_logs_seconds or PURGE BINARY LOGS) that the replica still needed, often after the replica was offline.
• A GTID gap: transactions the replica needs were purged, so its gtid_executed cannot be reconciled with the source’s available logs.
• The replica points at a binlog file/position that does not exist on the source (manual misconfiguration).
• The source’s binary log is corrupt or truncated (disk issue, unclean crash).
• The source’s server_id changed or binlogs were reset (RESET MASTER), invalidating the replica’s coordinates.
• A network interruption combined with binlog rotation losing the replica’s place.

How to Reproduce the Error

On a test source, purge binlogs the replica has not yet read, then start replication:

-- on source (test only): force purge of logs the replica still needs
PURGE BINARY LOGS BEFORE NOW();

mysql -e "START REPLICA;"
mysql -e "SHOW REPLICA STATUS\G" | grep Last_IO_Error

Last_IO_Error: Got fatal error 1236 from source ... 'Could not find first log file name'

The replica requests a purged log file, so the source returns fatal error 1236.

Diagnostic Commands

On the replica, read the full replication status (read-only):

mysql -e "SHOW REPLICA STATUS\G" | grep -E "Last_IO_Error|Source_Log_File|Read_Source_Log_Pos|Retrieved_Gtid_Set|Auto_Position"

Last_IO_Error: Got fatal error 1236 from source ...
Source_Log_File: binlog.000231
Read_Source_Log_Pos: 4
Auto_Position: 1

On the source, list which binary logs still exist (read-only):

mysql -e "SHOW BINARY LOGS;"
mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"
mysql -e "SELECT @@gtid_purged, @@gtid_executed\G"

If the file the replica wants is not in SHOW BINARY LOGS, it has been purged. Check the source error log and disk:

journalctl -u mysql --since "6 hours ago" --no-pager | grep -i binlog
df -h /var/lib/mysql

Step-by-Step Resolution

1. Confirm the cause. Compare the replica’s requested Source_Log_File/GTID against SHOW BINARY LOGS and @@gtid_purged on the source. A missing file or a needed GTID inside gtid_purged means the logs are gone.
2. If only a small gap and the needed binlog still exists, fix coordinates. For position-based replication: STOP REPLICA; CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='binlog.000231', SOURCE_LOG_POS=4; START REPLICA;
3. If using GTIDs and the gap is small, ensure SOURCE_AUTO_POSITION=1 and that the source still has the GTIDs; restart with START REPLICA;.
4. If the required logs are genuinely purged, the replica must be re-seeded from a fresh backup of the source (logical dump with GTID info, or a physical snapshot), then pointed at the corresponding position/GTID and restarted.
5. If the source binlog is corrupt, identify the bad file with mysqlbinlog, and re-seed the replica past the corruption.
6. After recovery, verify Replica_IO_Running: Yes and Replica_SQL_Running: Yes and that Seconds_Behind_Source trends to zero.

Prevention and Best Practices

• Set binlog_expire_logs_seconds long enough that a replica can be offline for your worst-case maintenance window and still catch up.
• Use GTID-based replication with SOURCE_AUTO_POSITION=1 so position drift is less error-prone, while still keeping enough binlog retention.
• Monitor replica lag and Replica_IO_Running so a stopped I/O thread pages you before logs are purged out from under it.
• Never RESET MASTER on a source with active replicas without re-seeding them.
• Keep binlog storage on reliable disks with monitoring, since corruption is a 1236 cause.
• Automate replica re-seeding so recovery from an unrecoverable gap is fast and repeatable.

Related Errors

• ERROR 1237 / Slave SQL thread errors — applier-side failures, distinct from the I/O-thread fetch failure.
• Last_SQL_Error: ... Could not execute ... — the SQL thread cannot apply an event (schema drift), unlike 1236 which is about fetching.
• ERROR 13117 / GTID errors like errant transactions — GTID inconsistencies that complicate 1236 recovery.
• Relay log read failure — corruption in the replica’s relay logs rather than the source’s binlogs.

Frequently Asked Questions

Can I fix 1236 without re-seeding? Only if the binlog/GTID the replica needs still exists on the source. If it was purged, re-seeding is required.

Why did purging happen? Binlog retention (binlog_expire_logs_seconds) expired logs while the replica was behind or offline. Longer retention prevents this.

Does GTID replication avoid 1236? It makes coordinate management safer, but a replica still fails with 1236 if the GTIDs it needs are inside the source’s gtid_purged set.

Is the data on the replica lost? Not the data already applied — but the replica is stale from the failure point. Re-seeding from a fresh backup brings it current.

How do I tell purge from corruption? If SHOW BINARY LOGS is missing the file, it was purged. If the file exists but mysqlbinlog errors reading it, it is corrupt. For deeper replication triage, see MySQL guides.