How to fix ERROR 1236: Got fatal error from master reading binary log in MySQL

MySQLADVANCEDHIGHUpdated Dec 25, 2025· 283 views

This replication error occurs on MySQL slaves when the master cannot send binary log events due to packet size mismatches, corrupted logs, or missing binary log files. It typically requires resynchronizing the replication connection or adjusting packet size settings.

Quick fix

Fixes 1236

STOP SLAVE;
  1. Stop the slave replication immediately
  2. Check max_allowed_packet on both servers
  3. Verify binary logs exist on the master
  4. Skip the problematic binary log and resume replication
mysql — error
STOP SLAVE;
ERROR 1236: Got fatal error from master reading binary log

What this error means

ERROR 1236 is a fatal replication error that occurs on the slave (replica) server when the replication I/O thread encounters a problem reading binary log events from the master. This is one of the most common MySQL replication failures. The error can originate from several distinct issues: binary log packets that exceed the maximum allowed size (max_allowed_packet mismatch between master and slave), corrupted or truncated binary log files on the master (usually from crashes without proper sync_binlog settings), missing binary log files that the slave still requires, or impossible replication positions that reference non-existent binary log offsets. When this error occurs, the slave's I/O thread stops, halting all replication until you intervene. The slave becomes out-of-sync with the master, potentially leading to data inconsistency if transactions continue on the master while the slave is stalled.

Typical symptoms

  • Slave replication stops with "Last_IO_Error: Got fatal error 1236 from master when reading data from binary log"
  • SHOW SLAVE STATUS shows Slave_IO_Running: No with error 1236
  • Replication lag increases as the slave falls behind the master
  • Error occurs immediately after master restart or during long-running bulk operations
  • Slave worked previously but fails after updating max_allowed_packet on master
  • "binlog truncated in the middle of event" or "log event entry exceeded max_allowed_packet" messages appear
  • AWS DMS CDC (Change Data Capture) tasks fail with error 1236 when using MySQL as source

Common causes

  1. max_allowed_packet mismatch: Master's max_allowed_packet is larger than slave's, causing oversized packets to be rejected
  2. Binary log corruption or truncation: Master crashed or was shut down ungracefully with sync_binlog != 1, leaving incomplete events in binary logs
  3. Binary log files purged: Master has deleted binary logs that the slave still needs, usually due to aggressive expire_logs_days settings
  4. Impossible replication position: Slave is trying to read from a binary log file or position that no longer exists on the master
  5. Missing or corrupted replication metadata: Slave's relay log information is out of sync with actual master state
  6. Encrypted binary logs in MySQL 8.0: AWS DMS and some replication tools cannot decrypt encrypted binary logs at initialization
  7. Disk full on master's temp directory (tmpdir): Causes binary log cache files to be truncated, corrupting binary log entries
  8. GTID purged on master: In GTID-based replication, master has purged GTIDs that slave needs to execute

How to fix "ERROR 1236: Got fatal error from master reading binary log"

1Stop the slave replication immediately

First, stop the slave to prevent further errors and lock the slave status:

sql
STOP SLAVE;

Then check the current replication status:

sql
SHOW SLAVE STATUS\G

Look for:
- Last_IO_Error: The specific error message
- Master_Log_File: The binary log file the slave was trying to read
- Read_Master_Log_Pos: The position where it failed
- Relay_Master_Log_File: The last successfully processed master log

2Check max_allowed_packet on both servers

This is the most common cause. The slave cannot receive packets larger than its max_allowed_packet setting.

On the master, check:

sql
SHOW VARIABLES LIKE 'max_allowed_packet';

On the slave, check:

sql
SHOW VARIABLES LIKE 'max_allowed_packet';
SHOW VARIABLES LIKE 'slave_max_allowed_packet';

If the master's max_allowed_packet is larger than the slave's, increase the slave's setting.

To fix (slave configuration):

Edit your slave's MySQL configuration file (/etc/mysql/mysql.conf.d/mysqld.cnf or /etc/my.cnf):

ini
[mysqld]
max_allowed_packet = 1G
slave_max_allowed_packet = 1G

Then restart MySQL on the slave:

bash
sudo systemctl restart mysql

For MySQL 5.6.6+, the slave_max_allowed_packet variable (default 1GB) overrides max_allowed_packet for replication threads, which is safer.

3Verify binary logs exist on the master

The slave may be trying to read a binary log file that no longer exists. Check which binary logs are available on the master:

On the master, run:

sql
SHOW BINARY LOGS;
-- or in older MySQL versions:
-- SHOW MASTER LOGS;

From the slave's SHOW SLAVE STATUS output, note the Master_Log_File value. If that file is not in the master's list, the logs were purged.

Check expiration settings on master:

sql
SHOW VARIABLES LIKE 'expire_logs_days';
-- MySQL 8.0.3+:
-- SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

If logs are being purged too aggressively, increase this value on the master:

ini
[mysqld]
expire_logs_days = 30  -- Keep logs for 30 days (MySQL 5.7)
-- Or in MySQL 8.0.3+:
binlog_expire_logs_seconds = 2592000  -- 30 days in seconds

If binary logs are already missing, you must rebuild the slave from a fresh backup (see Advanced Notes).

4Skip the problematic binary log and resume replication

If the binary log file is missing or corrupted and you've verified that binary logs exist on the master, move the slave to the next available binary log file:

First, check what binary logs are available on the master:

sql
SHOW BINARY LOGS;

Then on the slave, move to the first available binary log with position 4 (the start of each binary log file):

sql
STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000712', MASTER_LOG_POS=4;
START SLAVE;

Replace mysql-bin.000712 with the first available binary log from your master's SHOW BINARY LOGS output.

Verify replication resumed:

sql
SHOW SLAVE STATUS\G

Both Slave_IO_Running and Slave_SQL_Running should show Yes.

Warning: This approach skips any transactions from the missing binary log. The slave and master may be momentarily inconsistent. This is acceptable only if:
- You're willing to tolerate a brief data inconsistency
- The skipped transactions are not critical
- You plan to verify data consistency afterward (see Advanced Notes)

5Fix binary log sync settings on the master

Prevent future binary log corruption by ensuring the master durably writes binary logs to disk:

On the master, check:

sql
SHOW VARIABLES LIKE 'sync_binlog';
SHOW VARIABLES LIKE 'binlog_cache_size';
SHOW VARIABLES LIKE 'binlog_stmt_cache_size';

The key setting is sync_binlog:
- sync_binlog = 0 (default): OS controls when binlogs flush to disk (risky - data loss on crash)
- sync_binlog = 1: Every transaction commits to disk before returning success (safe but slower)
- sync_binlog = N (N > 1): Every Nth transaction syncs (compromise between safety and performance)

For production databases, enable safe binary log syncing:

Edit the master's MySQL configuration:

ini
[mysqld]
sync_binlog = 1

Also verify innodb_flush_log_at_trx_commit = 1 for full ACID compliance:

sql
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

If not set to 1, add to configuration:

ini
[mysqld]
innodb_flush_log_at_trx_commit = 1

Restart MySQL on the master:

bash
sudo systemctl restart mysql

Note: Setting sync_binlog = 1 impacts write performance (typically 5-10% slower), but is essential for replication reliability.

6Verify data consistency after recovery

After resuming replication, verify that master and slave are consistent. Data may have diverged if you skipped binary logs.

Option 1: Quick check using checksums (Percona Toolkit)

If you have Percona Toolkit installed:

bash
pt-table-checksum h=master-host --max-lag=60 --no-check-binlog-format

This compares master and slave data and reports differences.

Option 2: Manual consistency check

On both master and slave, run:

sql
SHOW MASTER STATUS\G  -- On master
SHOW SLAVE STATUS\G   -- On slave

Ensure the slave's Exec_Master_Log_Pos equals the master's Position, indicating the slave has caught up.

For specific tables, compare row counts:

sql
SELECT COUNT(*) FROM important_table;

If inconsistencies exist and the data is critical, you may need to rebuild the slave from a backup.

Advanced notes

Rebuilding slave from backup: If you cannot skip binary logs (too many transactions lost) or data consistency is critical, rebuild the slave from a master backup using mysqldump or Percona XtraBackup.

Using mysqldump with --master-data:

bash
mysqldump --skip-lock-tables --single-transaction --flush-logs --master-data=2 -h master-host -u root -p --all-databases > backup.sql
mysql -h slave-host -u root -p < backup.sql
# Then start replication with the position from backup.sql

Using Percona XtraBackup (faster for large databases):

bash
xtrabackup --backup --target-dir=/backup --host=master-host --user=root --password=pass
xtrabackup --prepare --target-dir=/backup
# Copy to slave and restore, then start replication

GTID replication: In MySQL 5.6+ with GTIDs enabled, use:

sql
CHANGE MASTER TO MASTER_HOST='master', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1;
START SLAVE;

The MASTER_AUTO_POSITION=1 setting handles position changes automatically, reducing manual intervention.

Encrypted binary logs (MySQL 8.0): If the master has encrypted binary logs, AWS DMS and some replication tools fail at initialization. Decrypt logs before replication or use a dedicated replication user with binary log decryption privileges.

Monitoring replication: Set up alerts for replication lag to catch error 1236 early:

sql
-- Monitor Seconds_Behind_Master
SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;

-- 0 = slave is caught up
-- NULL = replication is broken (slave stopped)
-- > 0 = slave is lagging

Common misconfiguration: Slave's server_id must differ from master's:

sql
SHOW VARIABLES LIKE 'server_id';
-- Should be different on master vs slave

Multi-source replication: In MySQL 5.7+, if using multi-source replication (replicating from multiple masters), error 1236 must be fixed per channel:

sql
SHOW SLAVE STATUS FOR CHANNEL 'channel_name'\G
CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=4 FOR CHANNEL 'channel_name';

Frequently asked questions

What does "1236" mean?
ERROR 1236 is a fatal replication error that occurs on the slave (replica) server when the replication I/O thread encounters a problem reading binary log events from the master. This is one of the most common MySQL replication failures. The error can originate from several distinct issues: binary log packets that exceed the maximum allowed size (max_allowed_packet mismatch between master and slave), corrupted or truncated binary log files on the master (usually from crashes without proper sync_binlog settings), missing binary log files that the slave still requires, or impossible replication positions that reference non-existent binary log offsets.
How do I fix "1236"?
This replication error occurs on MySQL slaves when the master cannot send binary log events due to packet size mismatches, corrupted logs, or missing binary log files. It typically requires resynchronizing the replication connection or adjusting packet size settings.
What causes "1236"?
max_allowed_packet mismatch: Master's max_allowed_packet is larger than slave's, causing oversized packets to be rejected Binary log corruption or truncation: Master crashed or was shut down ungracefully with sync_binlog != 1, leaving incomplete events in binary logs Binary log files purged: Master has deleted binary logs that the slave still needs, usually due to aggressive expire_logs_days settings
Is the "1236" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading