How to fix ERROR 1593: Error reading relay log in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 25, 2025· 203 views

MySQL ERROR 1593 indicates replication failure caused by a corrupted relay log file. The relay log stores replication data from the source server, and corruption typically results from hardware failures or unexpected server shutdowns. Fix by resetting the replica and resyncing from the source.

Quick fix

Fixes 1593

# On the source server
mysqlbinlog /path/to/binary/log/mysql-bin.XXXXXX | head -50
  1. Verify the source server's binary log is not corrupted
  2. Get current replication position from the replica
  3. Stop the replica
  4. Reset the replica and clear corrupted relay logs
mysql — error
# On the source server
mysqlbinlog /path/to/binary/log/mysql-bin.XXXXXX | head -50
ERROR 1593: Error reading relay log

What this error means

ERROR 1593 "Error reading relay log" occurs when MySQL replica (slave) cannot read its relay log file during replication. The relay log is a temporary binary log on the replica that stores changes received from the source (master) server before they're applied to the replica's database. When the relay log becomes corrupted—typically due to disk I/O errors, hardware failures, or abrupt server shutdowns—the SQL thread cannot continue processing replication events. This is a replication-critical error that stops the replica from applying changes, causing data divergence from the source. The error occurs specifically when the SQL thread tries to read and parse a relay log event to apply it to the replica's database. Unlike the I/O thread (which reads from the source), the SQL thread operates locally and will fail immediately if the relay log is unreadable.

Typical symptoms

  • Replication stops with Slave_SQL_Running showing NO
  • Error messages mentioning 'relay log' or event parsing failure
  • Replica data becomes out of sync with source/master
  • MySQL error log contains 'Error reading relay log event' messages
  • Database modifications from source are not applied to replica

Common causes

  1. Relay log file corruption due to disk I/O errors or bad sectors
  2. Server crash or ungraceful shutdown while writing to relay log
  3. Hardware failure causing filesystem corruption
  4. Insufficient disk space during relay log rotation
  5. Network disconnection during log file operations
  6. Bug in MySQL code (rare on modern versions)
  7. ARM platform memory consistency issues (MySQL 8.0 on ARM)

How to fix "ERROR 1593: Error reading relay log"

1Verify the source server's binary log is not corrupted

Run mysqlbinlog on the source server to ensure its binary log is healthy. Log in to the source server and check the binary log file:

bash
# On the source server
mysqlbinlog /path/to/binary/log/mysql-bin.XXXXXX | head -50

If mysqlbinlog fails with errors, the source's binary log is corrupted and must be recovered first before attempting to fix the replica.

If mysqlbinlog succeeds, proceed to the next step.

2Get current replication position from the replica

Before resetting the replica, capture the current replication position. Connect to the replica and run:

sql
SHOW REPLICA STATUS\G

(Or SHOW SLAVE STATUS\G on older MySQL versions)

Note these values—they may be useful for troubleshooting:
- Relay_Source_Log_File (or Relay_Master_Log_File): The binary log on the source
- Exec_Source_Log_Pos (or Exec_Master_Log_Pos): The last position executed

These will help you determine exactly where replication was interrupted.

3Stop the replica

Stop both the IO and SQL threads to prevent further errors:

sql
STOP REPLICA;

(Or STOP SLAVE; on older MySQL versions)

Verify both threads are stopped:

sql
SHOW REPLICA STATUS\G

Confirm that both Slave_IO_Running and Slave_SQL_Running are NO.

4Reset the replica and clear corrupted relay logs

Reset the replica to clear all replication metadata and remove corrupted relay log files:

sql
RESET REPLICA;

(Or RESET SLAVE; on older MySQL versions)

This command:
- Clears the master.info and relay-log.info metadata repositories
- Deletes ALL relay log files
- Creates a fresh relay log for new replication

This is safe because the relay log is temporary storage; all replication data can be re-fetched from the source.

5Reconfigure replication with source coordinates

Reconnect the replica to the source using the binary log position you noted earlier:

sql
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source-server-hostname',
  SOURCE_USER='replication-user',
  SOURCE_PASSWORD='replication-password',
  SOURCE_LOG_FILE='mysql-bin.XXXXXX',
  SOURCE_LOG_POS=XXXXXXXXX;

Replace:
- source-server-hostname: Hostname/IP of the source
- mysql-bin.XXXXXX: The Relay_Source_Log_File from step 2
- XXXXXXXXX: The Exec_Source_Log_Pos from step 2
- replication-user and password with your replication credentials

For older MySQL versions, use CHANGE MASTER TO instead.

If you're using GTIDs, use:

sql
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source-server-hostname',
  SOURCE_USER='replication-user',
  SOURCE_PASSWORD='replication-password',
  SOURCE_AUTO_POSITION=1;
6Start replication and monitor progress

Restart the replication threads:

sql
START REPLICA;

(Or START SLAVE; on older MySQL versions)

Check the replication status:

sql
SHOW REPLICA STATUS\G

Monitor these key fields:
- Slave_IO_Running: Should be YES (replica IO thread is reading from source)
- Slave_SQL_Running: Should be YES (replica SQL thread is applying changes)
- Seconds_Behind_Master: Should decrease toward 0 as replication catches up
- Last_Error: Should be empty if replication is healthy

Watch the error log for any new errors:

bash
# Check MySQL error log
tail -f /var/log/mysql/error.log | grep -i error

Replication will resync from the source and rebuild the relay log. The process time depends on how far behind the replica was.

Advanced notes

ARM Platform Considerations: MySQL 8.0 on ARM architecture sometimes encounters transient relay log read errors due to ARM's weak memory consistency. These errors may resolve on their own after restarting the SQL thread. If the issue persists, follow the full reset procedure above.

Relay Log Recovery: MySQL 5.7.3+ supports automatic relay log recovery with the relay_log_recovery system variable. Setting relay_log_recovery=1 in my.cnf enables automatic recovery from corrupted relay logs on startup. However, manual reset is more reliable for severe corruption.

GTID vs Binlog Position: If using GTIDs (Global Transaction Identifiers), the reset process is simpler—you can use SOURCE_AUTO_POSITION=1 to avoid calculating exact binlog positions. This is recommended for modern MySQL setups.

Prevention: Configure relay_log and relay_log_index system variables explicitly in my.cnf to use fixed file names independent of hostname changes. This prevents replication confusion if the replica hostname changes in DHCP environments.

Full Resync Alternative: If you suspect other data inconsistencies beyond relay log corruption, perform a full backup of the source and restore it on the replica, then restart replication from the current position. This is more time-consuming but ensures complete data integrity.

Frequently asked questions

What does "1593" mean?
ERROR 1593 "Error reading relay log" occurs when MySQL replica (slave) cannot read its relay log file during replication. The relay log is a temporary binary log on the replica that stores changes received from the source (master) server before they're applied to the replica's database. When the relay log becomes corrupted—typically due to disk I/O errors, hardware failures, or abrupt server shutdowns—the SQL thread cannot continue processing replication events.
How do I fix "1593"?
MySQL ERROR 1593 indicates replication failure caused by a corrupted relay log file. The relay log stores replication data from the source server, and corruption typically results from hardware failures or unexpected server shutdowns. Fix by resetting the replica and resyncing from the source.
What causes "1593"?
Relay log file corruption due to disk I/O errors or bad sectors Server crash or ungraceful shutdown while writing to relay log Hardware failure causing filesystem corruption
Is the "1593" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading