<p>The replication SQL thread could not delete outdated relay log files, halting replication cleanup.</p>
<p>MySQL Error 1371 ER_RELAY_LOG_FAIL occurs when the replication SQL thread fails to purge old relay log files. Verify disk permissions, free disk space, and the relay_log_purge setting, then manually execute PURGE BINARY LOGS or restart replication to clear the logs and resume normal operation.</p>
Failed purging old relay logs: %s
MySQL raises Error 1371 with the ER_RELAY_LOG_FAIL condition when the replication SQL thread cannot delete obsolete relay log files during cleanup. The message appears as Failed purging old relay logs: %s and halts automatic relay log maintenance.
Replication relies on relay logs to store events retrieved from a primary server. If these logs are not purged, disk space can fill up and replication performance degrades. Addressing the failure quickly prevents replica lag and potential outages.
The purge operation needs adequate file system permissions, available disk space, and correct server settings. Missing any of these prerequisites triggers ER_RELAY_LOG_FAIL. The error may also surface after abrupt server restarts or partial disk failures that corrupt relay log files.
Another frequent cause is relay_log_purge set to OFF while expire_logs_days or binlog_expire_logs_seconds try to remove files, creating conflicts that stop the purge process.
Start by checking the MySQL error log for additional context such as an I/O or permission error. Ensure the MySQL process owner can delete files in the relay-log directory and that the partition has sufficient free space.
If permissions and space look fine, manually purge binary and relay logs with SQL commands, then restart the replica threads. Disable relay_log_purge only for controlled maintenance tasks to avoid repeated failures.
On Linux systems with strict SELinux policies, the MySQL daemon may lack delete rights. Adjust security contexts or temporarily disable SELinux enforcing mode to allow the purge.
In cloud environments, auto-scaling storage can silently reach quota limits. Expanding the volume or moving the relay log directory fixes the space constraint and lets purging proceed normally.
Enable relay_log_purge and set appropriate expire_logs_days so cleanup runs automatically. Monitor disk usage on replicas and alert when relay log directories exceed thresholds.
Use Galaxy’s fast SQL editor to script periodic checks on SHOW SLAVE STATUS and the relay log directory size. Share endorsed monitoring queries in a Galaxy Collection so the entire team stays aware of replication health.
Replication setups frequently encounter MySQL Error 1595 Relay log read failure and Error 1236 Could not find first log file. These issues involve missing or unreadable relay logs and are resolved with similar permission, space, or file integrity checks.
Error 1201 could not connect to master indicates network or authentication problems, differing from ER_RELAY_LOG_FAIL but also halts replication. Fixing host connectivity or credentials eliminates that error.
The MySQL system user lacks OS-level delete privileges, preventing relay log removal.
The partition containing relay logs is full, so purge operations cannot allocate temporary resources required for deletion.
Setting relay_log_purge=OFF blocks automatic cleanup and eventually triggers the error when expire settings try to purge logs.
Unclean shutdowns or hardware faults leave relay log files partially corrupted, causing the purge routine to abort with Error 1371.
Indicates a damaged relay log file. Rebuild replication or re-sync the replica.
Occurs when referenced binary or relay logs are missing. Verify log retention policies.
Points to network or authentication issues between replica and primary.
The error halts relay log cleanup but the SQL thread may continue applying events until disk space runs out. Investigate quickly to avoid full stoppage.
Only delete relay logs after stopping replication with STOP SLAVE. Use RESET SLAVE to regenerate a clean set automatically.
Error 1371 exists in all 5.6, 5.7, 8.0, and 8.1 community and enterprise builds because relay log purging logic is unchanged.
Galaxy lets teams share replication health queries and automate checks, reducing the chance of unnoticed relay log buildup.
.avif)
.avif){kind=logo}
