MySQL Error 1885: ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER - Fix and Prevent Replication Drift

What is MySQL Error 1885 ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER?

Error 1885 signals that the replica's GTID_EXECUTED set contains one or more GTIDs absent from the primary's GTID_EXECUTED. Replication halts to protect data integrity.

The issue appears only in GTID-based replication introduced in MySQL 5.7.6 and later. It usually follows an unexpected primary failure or manual binlog manipulation.

Why Does This Error Matter?

When GTID consistency breaks, transactions may exist on the replica but not on the master. Continuing replication would silently diverge data, leading to inconsistent reads, failed promotions, and unsafe failovers.

Resolving the mismatch quickly restores a single source of truth and keeps high availability topologies healthy.

What Causes This Error?

MySQL raises Error 1885 when it computes the replica's GTID_PURGED and sees GTIDs not present on the primary. Common root causes include truncated binary logs, lost log files after disk failure, or a primary rollback following crash recovery.

Manual binlog deletion, replica delay settings combined with RESET MASTER, or running mysqld with sync_binlog set to 0 or 100 can also drop GTIDs from the master, triggering the error.

How to Fix ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER

First, identify the extra GTIDs on the replica with:

SELECT @@GLOBAL.gtid_executed G

Then compare against the primary:

SHOW GLOBAL VARIABLES LIKE 'gtid_executed';

If the transactions are safe to replay on the primary, extract them from the replica's relay logs and apply using mysqlbinlog or plain SQL. If they can be ignored, skip them on the replica with:

STOP SLAVE;
SET GTID_NEXT='gtid_to_skip';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

Alternatively, inject empty placeholders on the master:

SET GTID_NEXT='gtid_missing';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';

Common Scenarios and Solutions

Disk crash on master - copy last intact binlog to master, replay missing transactions, then restart replication.

Manual RESET MASTER on primary - clone GTID set from replica via empty commits to re-align GTID_EXECUTED.

Replication lag with rotated logs - configure relay_log_recovery=1 on replica and rebuild replica from fresh backup if GTID holes are large.

Best Practices to Avoid This Error

Enable sync_binlog=1 and innodb_flush_log_at_trx_commit=1 to guarantee durability of GTIDs to disk.

Never delete or rotate binary logs manually. Use PURGE BINARY LOGS with careful GTID checks.

Monitor GTID consistency with performance_schema.replication_connection_status or tools like pt-heartbeat.

Use Galaxy SQL editor collections to store vetted maintenance scripts so operators replay or skip GTIDs consistently across environments.

Related Errors and Solutions

Error 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG) - occurs when replica cannot read a corrupted binlog. Fix by copying intact log.

Error 1594 (ER_MASTER_NET_READ) - network read timeout between master and slave. Address latency or firewall issues.

Error 3102 (ER_GTID_PURGED_CAN_ONLY_BE_SET_ONCE) - raised when trying to reset GTID_PURGED twice. Reset replication or rebuild replica.