<p>A replica cannot start because the master has already removed binary logs that contain GTIDs the replica still needs.</p>
<p>MySQL Error 1789 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS appears when a replica connects with MASTER_AUTO_POSITION=1 but the master no longer holds the required GTID events. Restore the missing transactions or rebuild the replica from a fresh backup to resolve the issue.</p>
The slave is connecting using CHANGE MASTER TO
Error 1789 fires during replication startup when the slave requests transactions by GTID but the master no longer has those events in its binary log.
This situation prevents the replica from applying missing transactions and halts replication until manual intervention occurs.
The master purged binary logs too aggressively, deleting GTIDs the replica never fetched.
Long replication lag combined with a short binlog_expire_logs_seconds makes the gap likely.
Restore or re-apply the missing transactions from another peer, backup, or an external binary log archive.
When no source contains the events, rebuild the replica with a full backup taken after the purged GTIDs.
Adding a new replica: use a recent physical or logical backup of the master rather than starting from empty data files.
Replica after network outage: copy the missing binary logs from another replica that still holds them.
Set binlog_expire_logs_seconds longer than the maximum replica lag, including maintenance windows.
Monitor gtid_executed differences with Galaxy or other tools to alert before purge risk appears.
Error 1236 occurs for non-GTID replication when the requested binlog is missing. Error 1790 fires when a replica has extra GTIDs not present on the master.
The master deletes binlogs quickly because binlog_expire_logs_seconds is set too low for the environment.
Slow queries, network congestion, or resource limits cause the slave to fall far behind the master.
An administrator purged logs to free disk space without checking replica status.
No off-box archive of binlogs exists, making recovery harder when logs are lost.
Similar gap but in non-GTID replication.
The replica has GTIDs the master lacks, often after failover.
General missing binlog error when seeking a specific file.
Compare gtid_executed on the master and replica. The replica error output lists the first missing GTID.
Skipping risks data inconsistency. Only skip if you fully understand the business impact.
Set retention longer than the maximum expected replica lag plus extra buffer, often 7-14 days in production.
Galaxy tracks GTID lag and highlights risky purge settings, letting teams adjust binlog retention before an outage.
.avif)
.avif){kind=logo}
