MySQL Error 1236: "Got Fatal Error from Source When Reading Binary Log"

MySQL error 1236, "Got fatal error 1236 from source when reading data from binary log", means the source refused or failed to send the binary log events the replica asked for. The replica's receiver (I/O) thread stops, and the replica falls further behind every minute. The number alone tells you little. The text in quotes after it tells you what actually happened.

The MySQL error reference lists 1236 as ER_SOURCE_FATAL_ERROR_READING_BINLOG with the message Got fatal error %d from source when reading data from binary log: '%s'. The %s part is filled in by the source. In practice it is almost always one of four messages, and they need different fixes.

Get the full error first

-- on the replica
SHOW REPLICA STATUS\G
--   Replica_IO_Running: No
--   Replica_SQL_Running: Yes
--   Source_Log_File: binlog.004812
--   Read_Source_Log_Pos: 82731455
--   Last_IO_Errno: 1236
--   Last_IO_Error: Got fatal error 1236 from source when reading data
--                  from binary log: '...the part that matters...'
--   Auto_Position: 1

-- on the source: which binary logs still exist?
SHOW BINARY LOGS;

In SHOW REPLICA STATUS, Source_Log_File and Read_Source_Log_Pos show where the receiver thread stopped reading. Last_IO_Error holds the full message, which is also written to the replica's error log. Auto_Position: 1 means the channel uses GTID auto-positioning, and that changes which variant of the error you will see. Compare the file name with what SHOW BINARY LOGS lists on the source.

1. "Could not find first log file name in binary log index file"

The replica asked for a binary log file the source no longer has. This is the most common variant on position-based replication. Typical causes:

• The file expired. MySQL removes old binary logs automatically after binlog_expire_logs_seconds, which defaults to 2592000 seconds, or 30 days (binary log options). A replica that was down, stopped or broken for longer than that cannot continue.
• Someone purged it. The PURGE BINARY LOGS documentation is explicit: purging is safe for connected replicas, because files still being read are kept, but if a replica is not connected and you purge a file it has yet to read, it cannot replicate after reconnecting. We covered safe purging in MySQL purge binary logs.
• The source is not the server the replica thinks it is. After a failover, a rebuild or RESET BINARY LOGS AND GTIDS on the source, the old file names and positions mean nothing.

If the file the replica needs is gone, the transactions in it are gone from this source too. Pointing the replica at the oldest file that still exists makes the error disappear, but the replica silently skips everything in between and its data no longer matches the source. You will find out later, usually as duplicate key error 1062 or wrong query results. The safe fix is to rebuild the replica, or to recover the missing files from a binary log backup if you have one.

2. The source has purged GTIDs the replica needs

With GTID auto-positioning, the same situation produces a clearer message, error 1789 ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS: "Cannot replicate because the source purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new replica from backup." The GTID auto-positioning documentation adds that the missing GTIDs are listed in the source's error log as ER_FOUND_MISSING_GTIDS, and that the replica cannot recover automatically.

• Check other servers. Another replica or an old source may still have the missing transactions in its binary logs. If so, the replica can get them from there.
• Otherwise rebuild the replica from a more recent backup or a clone.
• Do not switch off auto-positioning to get past it. The documentation warns that reconnecting without SOURCE_AUTO_POSITION only results in losing the purged transactions on the replica.

3. "binlog truncated in the middle of event; consider out of disk space on source"

The source found an incomplete event at the position the replica asked for. The message itself points to the most common reason: the source ran out of disk space while writing the binary log. Another possibility is a crash with relaxed durability settings. The default sync_binlog = 1 syncs the binary log to disk before commit, and the documentation says this guarantees that no transaction is lost from the binary log after a power failure or OS crash. Servers running with a higher value do not have that guarantee.

• Check free space on the source's binary log volume first, and fix it.
• Read the file around the reported position with mysqlbinlog to see whether the event is really damaged or the replica simply asked for a position that is not an event boundary.
• If the binary log is really damaged, the replica cannot be sure what it missed. Rebuilding it is the safe option.

4. "log event entry exceeded max_allowed_packet; Increase max_allowed_packet on source"

The event is bigger than the packet limit allows. Large row-based events come from big transactions, for example one UPDATE or DELETE touching millions of rows, or rows with large BLOB/JSON values. The replica options page explains that a source can write events longer than its max_allowed_packet once the event header is added, so replica_max_allowed_packet on the replica must be larger than max_allowed_packet on the source. Its default, and maximum, is 1 GB.

Raise the settings if they are below that, but also look at the transaction itself. An event near 1 GB usually means a batch job that should be split into smaller chunks. A position that points into the middle of an event can also produce misleading size errors, so check the coordinates if the setting already looks generous.

Rebuilding the replica

For most 1236 cases the real fix is a fresh copy. On MySQL 8.4 the clone plugin is usually the fastest route: CLONE INSTANCE FROM copies a donor's data directory over the network. The cloning for replication page explains that with GTIDs on, the donor's gtid_executed is applied on the recipient, so auto-positioning can pick up from there. For position-based replication, the coordinates are in performance_schema.clone_status.

-- on the new replica, after CLONE INSTANCE FROM ... has finished
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'db-primary', SOURCE_PORT = 3306,
  SOURCE_USER = 'repl', SOURCE_PASSWORD = '...',
  SOURCE_SSL = 1,
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

What changes on large servers

• Rebuilding takes hours or days. Copying several terabytes over the network or restoring a large backup is slow. During that time the source must keep every binary log the new replica will need, starting from the backup point. If retention is shorter than the rebuild, the new replica hits error 1236 again as soon as it starts.
• Size retention from real binlog volume. Add up the sizes from SHOW BINARY LOGS per day. Busy servers can write hundreds of gigabytes of binary logs a day. Retention has to cover the longest replica outage you can tolerate plus the time to rebuild, and the disk has to hold it.
• Watch the receiver thread, not only lag. Once the applier has consumed the relay log and the receiver thread is not running, Seconds_Behind_Source becomes NULL, and some dashboards then show no lag at all. Alert on the thread state and on Last_IO_Errno, so you have days to react, not minutes before the logs expire.
• Delayed and reporting replicas are the usual victims. They are the ones nobody looks at until they are needed. Include them in the retention calculation.
• Avoid huge transactions. Big batch deletes and updates create large events, slow down every replica and are the main trigger for the max_allowed_packet variant. Split them into chunks.

-- how long the source keeps binary logs (default 2592000 s = 30 days)
SELECT @@binlog_expire_logs_seconds / 86400 AS retention_days,
       @@binlog_expire_logs_auto_purge;

-- example: keep 14 days
SET PERSIST binlog_expire_logs_seconds = 1209600;