<p>MySQL skips a relay-log transaction because it was already executed and written to the binary log.</p>
<p>MySQL Error 1771 ER_SKIPPING_LOGGED_TRANSACTION appears when a replica finds a transaction in its relay log that is already recorded in its binary log or GTID set. The server skips the duplicate to keep data consistent. Resetting relay logs or repositioning replication usually resolves the issue.</p>
Skipping transaction %s because it has already been
The server raises Error 1771 with the message Skipping transaction %s because it has already been executed and logged when a replica examines its relay log and detects a transaction that is already present in its own binary log or GTID execution set.
The error is informational rather than fatal, but repeated skips indicate replication drift, potential data loss, or performance lag, so engineers should investigate and correct the underlying cause quickly.
The error usually occurs in GTID-based replication when relay logs contain transactions that the replica has already committed. It can also appear after manual point-in-time recovery, relay-log corruption, or server crashes that leave duplicate events in the relay log.
Because the replica relies on GTID_EXECUTED or binary log positions to decide what to apply, any mismatch between the relay log contents and those metadata values triggers the skip decision and logs Error 1771.
Confirm that the replica is otherwise healthy, then decide whether to purge or reprocess relay logs. The most common remedy is to reset the relay log files so the replica retrieves a clean stream from the source and continues applying events without duplicates.
If GTID replication is enabled, ensure gtid_purged and gtid_executed accurately reflect the replica's true state before restarting replication to prevent reappearance of duplicate entries.
After an unexpected shutdown, relay-log events may be re-fetched. Resetting the slave and skipping to the correct master log file removes duplicates.
When cloning data or using backup restore, GTID sets can be out of sync. Align gtid_purged with the source, then start slave to avoid skipped transactions.
Always stop replication cleanly before performing maintenance, and flush logs to create clear binary-log boundaries.
Use GTID-consistent backups, and never copy relay logs between servers. Monitor replication lag and error logs in Galaxy or other observability tools to catch duplicate events promptly.
Errors 1236 (HY000) and 1594 (HY000) also arise from relay-log issues. They differ by halting replication instead of silently skipping. Fixes include CHANGE MASTER TO MASTER_LOG_FILE and RESET SLAVE.
The replica's gtid_executed already contains the GTID of the next relay-log event, so MySQL skips it.
Hardware or disk issues write the same event twice in the relay log, producing a duplicate when processed.
Restoring from an inconsistent backup leaves the binary log ahead of the relay log.
Incorrect log file/position causes the replica to request an already applied event.
This fatal replication error occurs when the replica requests a binary-log file that no longer exists on the source. Use CHANGE MASTER TO to re-point to a valid log file.
An IO or disk issue prevents the replica from reading its relay log. Reset or rebuild the relay log to resume replication.
Indicates problems initializing relay logs after RESET SLAVE. Verify file permissions and disk space.
No. The replica simply skips the duplicate event and continues, but repeated occurrences signal an underlying problem.
Usually not, because the transaction already exists in the replica's data set. However, verify data consistency with checksums.
One-off skips are safe to ignore. Frequent skips require investigation to avoid hidden replication drift.
Galaxy surfaces replication warnings in its results pane and lets you run RESET SLAVE or CHANGE MASTER scripts directly from its editor, reducing recovery time.
.avif)
.avif){kind=logo}
