MetricSign
Start free
Critical severityconfiguration

MySQL Error:
1236

What does this error mean?

MySQL replication breaks when the replica requests a binary log position that the primary cannot serve. The replica's I/O thread stops with 'Got fatal error 1236 from master when reading data from binary log'. In a data-pipeline context this means any ADF linked service, Power BI DirectQuery connection, or ETL job reading from that replica instantly gets stale or missing data. The error is non-recoverable without manual intervention — MySQL will not auto-retry or skip ahead. Engineers typically see this after binlog rotation, primary failover, or when expire_logs_days is set too aggressively relative to replica lag.

Common causes

  • 1The binary log file referenced in the replica's relay log info was purged on the primary because expire_logs_days or binlog_expire_logs_seconds expired before the replica could fetch it.
  • 2The primary was restored from a backup (point-in-time recovery or snapshot) and now has a different GTID set or binlog sequence than the replica expects.
  • 3Binary log corruption on the primary due to disk failure, forced shutdown (kill -9), or incomplete fsync — the replica reads an invalid event checksum.
  • 4The replica's MASTER_LOG_POS points past the end of the current binlog file, often caused by manual CHANGE MASTER TO with incorrect coordinates.
  • 5A network partition caused the replica to fall behind far enough that all binlogs covering the gap were rotated out before connectivity resumed.
  • 6max_binlog_size was reduced on the primary, causing faster rotation than the replica's fetch rate can keep up with under heavy write load.

How to fix it

  1. 1Step 1: On the replica, stop replication and check where it's stuck: `STOP SLAVE; SHOW SLAVE STATUS\G` — note Master_Log_File and Read_Master_Log_Pos.
  2. 2Step 2: On the primary, verify which binlogs still exist: `SHOW BINARY LOGS;` — if the file from Step 1 is missing, the replica needs re-initialization.
  3. 3Step 3: If using GTIDs, check the GTID gap: `SELECT @@global.gtid_executed;` on both primary and replica to confirm what transactions are missing.
  4. 4Step 4: Take a consistent backup of the primary: `mysqldump --single-transaction --master-data=2 --all-databases > primary_backup.sql` or use xtrabackup --backup --target-dir=/backup.
  5. 5Step 5: On the replica, restore the backup: `mysql < primary_backup.sql` then extract the CHANGE MASTER coordinates from the backup header comment.
  6. 6Step 6: Reconfigure replication with correct coordinates: `RESET SLAVE ALL; CHANGE MASTER TO MASTER_HOST='primary', MASTER_LOG_FILE='mysql-bin.000047', MASTER_LOG_POS=154; START SLAVE;`
  7. 7Step 7: Verify replication is running and catching up: `SHOW SLAVE STATUS\G` — confirm Slave_IO_Running=Yes, Slave_SQL_Running=Yes, and Seconds_Behind_Master is decreasing.

Example log output

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from position > file size; the first event 'mysql-bin.000031' at 4, the last event read from '/var/log/mysql/mysql-bin.000031' at 4, the last byte read from '/var/log/mysql/mysql-bin.000031' at 4.'

Frequently asked questions

How do I prevent MySQL binlog purging from breaking replication?

Set binlog_expire_logs_seconds (MySQL 8.0+) or expire_logs_days (5.7) to at least 7 days — longer if your replicas regularly lag behind. Monitor Seconds_Behind_Master and alert if it exceeds 50% of your expiry window. For GTID-based replication, also ensure gtid_purged on the primary doesn't advance past what the replica has fetched.

How do I re-initialize a MySQL replica after error 1236?

Take a consistent backup with mysqldump --single-transaction --master-data=2 or Percona XtraBackup. Restore on the replica, then RESET SLAVE ALL and issue CHANGE MASTER TO with the coordinates from the backup. For databases over 100 GB, xtrabackup is significantly faster than mysqldump because it copies datafiles directly.

Can I skip the missing binlog events instead of re-initializing?

No. Error 1236 means the entire binlog file is unavailable, not a single event. SET GLOBAL sql_slave_skip_counter only works for individual event errors (like 1062 duplicate key). With 1236, the I/O thread cannot read anything — the only fix is re-establishing the replica from a position the primary can still serve.

Does error 1236 cause data loss in my ADF pipelines?

Not data loss on the primary, but data staleness downstream. ADF pipelines reading from the broken replica will either fail (connection refused) or return data frozen at the last successful replication point. If your pipeline uses incremental loads based on timestamps from the replica, you may miss rows until replication catches up after re-initialization.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html

Other configuration errors