MySQL Slave IO Thread Stopped Fix – 5 Real Steps

Quick answer (for those who know what they're doing)

Run STOP SLAVE; then RESET SLAVE ALL; then CHANGE MASTER TO master_log_file='mysql-bin.XXXXXX', master_log_pos=4; using the master's current binlog file and position from SHOW MASTER STATUS;. Then START SLAVE;.

What's actually happening here

Your MySQL slave IO thread stopped. The replication link between master and slave is broken. The slave's IO thread fetches binlog events from the master. When it can't read the next event — maybe the binlog got corrupted, or the slave's recorded position points to a file the master already purged — the thread stops dead. Error 1236 is the classic: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' or similar.

This happens most often after a master crash, a disk fill-up, or someone accidentally deleted binlogs on the master. The slave still thinks the next event is in a binlog file that no longer exists. You can't just restart the slave and expect it to work.

Fix steps (numbered, do them in order)

1. Stop the slave thread. Run STOP SLAVE; on the slave. This kills both IO and SQL threads. Nothing happens until you restart.
2. Check the master's current binlog position. On the master server, run SHOW MASTER STATUS;. Write down the File and Position values. Example: mysql-bin.000043 and 154.
3. Reset the slave's replication info. On the slave, run RESET SLAVE ALL;. This clears all master info and relay logs. Don't skip this — just using CHANGE MASTER TO without reset leaves old relay logs that can confuse things.
4. Point the slave to the master's current binlog. Run:
   

   CHANGE MASTER TO
     MASTER_HOST='your_master_ip',
     MASTER_USER='replica_user',
     MASTER_PASSWORD='your_password',
     MASTER_LOG_FILE='mysql-bin.000043',
     MASTER_LOG_POS=154;

   
   Replace the file and position with what you got from step 2.
5. Start the slave. Run START SLAVE;. Then check with SHOW SLAVE STATUS \G — look for Slave_IO_Running: Yes and Slave_SQL_Running: Yes.

If the main fix doesn't work

Sometimes the slave still throws error 1236 after re-pointing. That means the master's binlog file itself is corrupted or the master's position is wrong. Try these alternatives in order:

• Skip the corrupted event. If the slave SQL thread is also stopped, you might skip one or more events. Run SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; then START SLAVE; and check status. Repeat as needed — but you risk data inconsistency. Only do this if you know the skipped transaction is harmless.
• Use --skip-slave-start and manual binlog position. Stop MySQL on the slave, start it with --skip-slave-start, then use CHANGE MASTER TO with a binlog position slightly ahead of the broken one. You'll need to determine the last good position by examining the master's binlog with mysqlbinlog.
• Re-initialize the slave from a fresh backup. This is the nuclear option but reliable. Take a full backup of the master with mysqldump --master-data=2 or xtrabackup, restore it on the slave, and let it catch up from scratch. This guarantees clean binlog consumption.

Prevention tip

Set a reasonable binlog retention policy. On the master, configure expire_logs_days = 7 (or binlog_expire_logs_seconds in MySQL 8.0+). Also monitor the slave's Seconds_Behind_Master. If the slave falls behind more than the binlog retention window, you'll hit this exact error. Set up alerts when Seconds_Behind_Master exceeds, say, 3600 seconds. The fix is easier with warning than after the fact.

Also consider using GTID-based replication if you're on MySQL 5.6+. GTID makes repositioning simpler — you don't track file names and positions. With GTID, you'd just RESET SLAVE ALL; and CHANGE MASTER TO MASTER_AUTO_POSITION=1;. But that's a separate setup decision, not a fix for an already broken non-GTID slave.