The replica cannot connect because the primary has already purged binary logs that contain GTIDs the replica still needs.
MySQL error 1888 ER_FOUND_MISSING_GTIDS occurs when a replica requests GTIDs that the primary has already deleted from its binary logs. Re-seed the replica from a recent backup or transfer the missing logs, then raise binlog_expire_logs_seconds on the primary to prevent future purges.
ER_FOUND_MISSING_GTIDS
MySQL throws error 1888 ER_FOUND_MISSING_GTIDS when a replica connects to a source that no longer retains the binary logs containing the Global Transaction Identifiers (GTIDs) the replica requires. Replication halts immediately.
The problem is serious because GTID-based replication cannot skip or guess missing transactions. Until the replica receives every requested GTID, data divergence is possible and the channel stays stopped.
The error surfaces during CHANGE MASTER TO, START SLAVE, or automatic reconnections. It primarily affects GTID-enabled topologies on MySQL 5.7.29 and later, where binary log purge policies are aggressive.
Cloud environments that auto-purge logs and on-prem clusters with low binlog_expire_logs_seconds are most vulnerable, especially if replicas lag for hours or days.
Replication outages delay downstream analytics, backups, and disaster-recovery strategies. The longer a replica remains stopped, the larger its data gap grows, increasing recovery time objectives (RTOs).
In HA setups using semi-sync or group replication, missing GTIDs can also block failover because candidates may lack required transactions.
binlog_expire_logs_seconds or expire_logs_days is set too low, causing the primary to purge logs still needed by slow replicas.
Resource-constrained replicas fall behind, leaving more time for the primary to delete the relevant binary logs.
DBAs may purge logs by filename or date without checking replica positions, destroying required GTIDs.
Disk pressure triggers emergency purges or script-based deletions of old logs, leading to gaps.
Could not find first log file name in binary log index - occurs with file-based replication when logs are missing.
Net error reading from master - network interruptions can lead to lag that later triggers error 1888.
Could not initialize master info structure - often follows file permission or missing file issues.
No. GTID replication requires every transaction. Skipping would corrupt data consistency.
Longer retention consumes disk but has negligible CPU or memory cost. Monitor disk space and rotate logs to archive storage if needed.
Galaxy surfaces replica lag metrics and supports saved queries that alert when primary binary logs near expiration, letting teams act before purges.
The condition code was added in 5.7.29, but the underlying issue exists in 8.0 and MariaDB with similar messages.
.avif)
.avif){kind=logo}
