Why Does MySQL Replication Throw ER_MASTER_HAS_PURGED_REQUIRED_GTIDS and How to Fix It?

Background

Scenario: MySQL 5.7.12 with GTID enabled, dual primary servers M1 and M2, and a slave S1 using RC isolation level. A network fluctuation caused S1’s master to switch from M1 to M2, after which replication failed.

Error Message

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.’

Analysis

The error indicates that M2 has purged GTIDs that S1 still needs, causing the replication failure.

Investigation

Checked the binlog on M2 and found the logs were present, yet the error persisted. Examining the MySQL source code (rpl_binlog_sender.cc line 744) reveals the exact check that triggers the error:

if (!gtid_state->get_lost_gtids()->is_subset(m_exclude_gtid)) {
    errmsg = ER(ER_MASTER_HAS_PURGED_REQUIRED_GTIDS);
    global_sid_lock->unlock();
    set_fatal_error(errmsg);
    return 1;
}

This code runs when the master initializes the dump thread and verifies whether the slave can continue syncing. The master must not purge transactions that the slave has not yet executed.

Root Cause

Although M2’s binlog files had not been manually purged, the GTID_PURGED information on M2 contained entries originating from M1. Because neither M1 nor M2 had slave‑log‑update enabled, S1 could not receive M1’s transactions after switching to M2. During the switch, M2 replayed some of M1’s transactions and purged them, so S1’s executed_gtid range was lower than the master’s GTID_PURGED range, triggering the error.

Resolution

To recover, the team temporarily used log_file and position to re‑establish synchronization, then purged on S1 the GTIDs that the master had already purged, and finally resumed replication with auto_position=1.

Conclusion

When a slave’s executed GTID is less than the master’s GTID_PURGED, MySQL aborts replication with ER_MASTER_HAS_PURGED_REQUIRED_GTIDS. The reliable fix is to purge on the slave the GTIDs already removed on the master and restart replication using auto_position=1. The two essential conditions are: (1) the master must not purge GTIDs the slave has not executed, and (2) the master’s GTID range must fully encompass the slave’s executed GTID range.