<p>The slave SQL thread cannot read the relay log, halting replication.</p>
<p>MySQL Error 1594 ER_SLAVE_RELAY_LOG_READ_FAILURE means the slave SQL thread failed to read its relay log, stopping replication. Verify disk space, file and directory permissions, data corruption, and then restart replication with RESET SLAVE or CHANGE MASTER TO to fix the issue.</p>
Relay log read failure: %s
MySQL raises this replication error when the slave SQL thread tries to read the relay log but encounters an IO or corruption problem. The server stops applying relay log events, sets the SQL thread to the error state, and replication lag grows indefinitely until the issue is fixed.
The message usually appears in the error log as Relay log read failure: filename, together with the exact file and position that the SQL thread could not process. Because replication stops, downstream applications may see stale data, making quick remediation essential.
The condition arises during row or statement based replication on any MySQL version that uses relay logs, including community MySQL, Percona Server, and MariaDB. The slave must read relay log segments written by the IO thread. If the operating system cannot deliver the file cleanly, or if the relay log is missing or corrupted, the SQL thread fails immediately and surfaces error 1594.
Environments with poor network links, disk shortages, or manual file manipulation are most prone. Containerised or cloud databases with aggressive storage scaling can also trigger this failure when old relay log parts are evicted unexpectedly.
SHOW SLAVE STATUSdisplays SQL thread state as Slave SQL running No, together with Last_SQL_Error containing error 1594. Seconds_Behind_Master becomes NULL. The server error log mirrors these clues with a Relay log read failure line.
Applications continue to connect but read outdated data because replication stopped. Monitoring systems usually alert on replication delay or SQL thread stopped.
Leaving the slave broken risks data divergence, increases failover recovery time, and may cause permanent lag when the master continues to grow. Fast detection and repair ensures high availability architectures remain reliable.
An unexpected server shutdown or faulty storage device writes incomplete bytes into the relay log, making the SQL thread unable to parse the next event.
If the filesystem that stores relay-log files runs out of space or turns read only after an IO error, the SQL thread cannot access the file.
Accidental removal or rotation of relay-log files before the SQL thread finishes processing triggers the failure.
Misconfigured ownership or chmod settings block the mysqld process from reading relay-log files.
An unstable network drops packets while the IO thread is writing the relay log, leaving broken events on disk.
The IO thread cannot write to the relay log due to disk or permission issues, halting replication earlier in the pipeline.
The slave IO thread stops because it cannot read the master's binary log, usually due to network or master crash.
Duplicate key errors appear when data divergence exists, often after fixing relay log failures without cleansing inconsistent rows.
Row based replication cannot find the expected row for DELETE or UPDATE, indicating missing data on the slave.
Yes. SET GLOBAL sql_slave_skip_counter = 1 followed by START SLAVE advances past one event, but use only when you fully understand the business impact of losing that event.
It removes relay logs and replication metadata but leaves transactional data intact. The slave will download fresh events from the master.
Use reliable storage, enable crc32 checksums on relay logs, keep the server on a stable power supply, and monitor dmesg for disk IO errors.
MySQL 8 adds crash safe replication and improved relay log checksums that reduce but do not eliminate the risk. Keeping current helps.
.avif)
.avif){kind=logo}
