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

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

STOP SLAVE;

Then check the current replication status:

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

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

On the master, check:

SHOW VARIABLES LIKE 'max_allowed_packet';

On the slave, check:

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):

[mysqld]
max_allowed_packet = 1G
slave_max_allowed_packet = 1G

Then restart MySQL on the slave:

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.

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:

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:

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:

[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).

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:

SHOW BINARY LOGS;

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

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:

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)

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

On the master, check:

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:

[mysqld]
sync_binlog = 1

Also verify innodb_flush_log_at_trx_commit = 1 for full ACID compliance:

SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

If not set to 1, add to configuration:

[mysqld]
innodb_flush_log_at_trx_commit = 1

Restart MySQL on the master:

sudo systemctl restart mysql

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

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:

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:

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:

SELECT COUNT(*) FROM important_table;

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