EC
1236
MySQLERRORCommonReplicationHIGH confidence

Fatal error reading from binary log on master

Production Risk

Critical — replica is stopped and cannot catch up without re-initialization.

What this means

ER_MASTER_FATAL_ERROR_READING_BINLOG (1236, SQLSTATE HY000) is raised on the replica when the master reports a fatal error while the replica I/O thread is reading the binary log. Common causes include the requested binlog position not existing on the master.

Why it happens
  1. 1Replica is trying to read a binary log file or position that no longer exists on the master (purged)
  2. 2Binary log corruption on the master
  3. 3GTID position mismatch after failover
How to reproduce
trigger — this will error
trigger — this will error
-- On replica: SHOW SLAVE STATUSG
-- Slave_IO_Running: No
-- Last_IO_Error: Got fatal error 1236 from master when reading data from binary log

expected output

ERROR 1236 (HY000): Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000050' at 4, the last event read from 'mysql-bin.000051' at 4, the last byte read from 'mysql-bin.000051' at 4.'

Fix 1

Re-sync replica from a fresh snapshot

Re-sync replica from a fresh snapshot
-- Take a new snapshot of master and restore to replica
-- Then CHANGE MASTER TO with new MASTER_LOG_FILE and MASTER_LOG_POS
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000100', MASTER_LOG_POS=4;
START SLAVE;

Why this works

If the required binlog is purged, the replica must be re-initialized from a current backup.

Fix 2

Prevent premature binlog purge

Prevent premature binlog purge
SET GLOBAL expire_logs_days = 14;
-- Or:
SET GLOBAL binlog_expire_logs_seconds = 1209600;

Why this works

Keeping binary logs longer ensures replicas that fall behind can still catch up.

Sources
Official documentation ↗

MySQL 8.0 — 1236 ER_MASTER_FATAL_ERROR_READING_BINLOG

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All MySQL errors