Disk write failure during relay log rotation: the OS flushed a partial block to disk (e.g. during a RAID rebuild or NVMe controller reset), leaving the active relay log with a truncated or zero-padded tail that the SQL thread cannot parse.. Unclean replica shutdown (OOM kill, power loss, `kill -9` on mysqld) while the SQL thread was mid-event: the relay log index file records a log that was never fully written, so on restart MySQL tries to open a file that ends at an unexpected byte offset.. Relay log index out of sync: someone manually deleted relay log files from disk (e.g. to free space) without running `PURGE RELAYLOG` — the index still references files that no longer exist, causing an immediate read failure on the next SQL thread cycle.. Incompatible relay log format after an in-place upgrade: upgrading the replica from MySQL 5.7 to 8.0 without resetting replication can leave relay logs written in the old binary log event format; the 8.0 SQL thread rejects events it cannot decode.. Network filesystem latency (NFS, EFS, Azure Files) causing relay log writes to be buffered in the client cache but not yet visible on the OS read path — the SQL thread reads a stale inode size and interprets the gap as corruption.. Checksum mismatch when `binlog_checksum` differs between primary and replica: if the primary emits CRC32-checksummed events and the replica's `slave_sql_verify_checksum` sees a relay log written by a different primary (e.g. after a failover), the checksums will fail verification and trigger 1594.. Relay log filled the partition to 100%: `relay_log_space_limit` was not set, the partition ran out of inodes or bytes, and the partial write that was in progress at the moment of exhaustion left the file unreadable.

Step 1 — Capture current replication state before touching anything: `SHOW SLAVE STATUS\G` — note `Relay_Log_File`, `Relay_Log_Pos`, `Master_Log_File`, `Exec_Master_Log_Pos`, and the full error text in `Last_SQL_Error`. Save this output; you will need the master log coordinates in step 4.. Step 2 — Stop the replica threads cleanly: `STOP SLAVE;` (MySQL 5.7) or `STOP REPLICA;` (MySQL 8.0+). Do not skip this step — resetting a running replica can corrupt the relay log index further.. Step 3 — Reset all relay logs: `RESET SLAVE;` (5.7) or `RESET REPLICA;` (8.0). This deletes all relay log files on disk and clears the relay log index. The replication credentials and master coordinates in `master.info` / `mysql.slave_master_info` are preserved unless you add `ALL`.. Step 4 — Re-point the replica to the primary using the master coordinates from step 1: `CHANGE MASTER TO MASTER_HOST='primary_host', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='...', MASTER_LOG_FILE='binlog.000123', MASTER_LOG_POS=4567890;` — use `Exec_Master_Log_Pos` (not `Read_Master_Log_Pos`) as the position to avoid replaying already-applied transactions.. Step 5 — Enable automatic relay log recovery to prevent recurrence: add `relay_log_recovery = ON` to the `[mysqld]` section of `/etc/mysql/my.cnf` (or `/etc/my.cnf`). With this setting, MySQL automatically discards and re-fetches relay log contents from the primary on every replica restart, bypassing any on-disk corruption.. Step 6 — Start replication and verify: `START SLAVE;` then immediately run `SHOW SLAVE STATUS\G` — confirm `Slave_IO_Running: Yes`, `Slave_SQL_Running: Yes`, and watch `Seconds_Behind_Master` trending down toward 0. If `Last_SQL_Error` still shows 1594, the relay log written in this session is also corrupted, indicating a deeper disk problem; inspect `dmesg` and SMART data.. Step 7 — If the replica has diverged or the required binlog position is no longer on the primary (purged): take a fresh snapshot from the primary (e.g. `mysqldump --single-transaction --master-data=2` or Percona XtraBackup), restore it on the replica, and bootstrap replication from the `CHANGE MASTER TO` coordinates embedded in the dump header.

Critical severityconfiguration

MySQL Error:
1594

Impact

The moment 1594 fires, replication halts completely — no further events are applied until you manually intervene. Every ADF copy activity that reads from the replica returns stale rows without any error (the query succeeds, the data is just old), and Power BI Direct Query datasets silently report yesterday's figures. If the replica is your CDC source, downstream tables stop advancing and any SLA on data freshness is breached immediately.

Replication halts the instant 1594 fires — there is no automatic retry. ADF copy activities that read from the replica continue to succeed at the SQL level but return stale data, making the failure invisible in pipeline run logs until a data quality check catches the drift. If `Seconds_Behind_Master` is monitored, it will climb indefinitely. Any SLA requiring data freshness within a window (e.g. hourly refresh, T+1 warehouse loads) is breached for the full duration of the outage, which typically spans the time from the crash to the next manual intervention.

What does this error mean?

MySQL replication uses relay logs as an intermediary buffer: the I/O thread writes events fetched from the primary into relay logs on disk, and the SQL thread reads those events to replay them locally. Error 1594 means the SQL thread failed to read from the relay log — typically because the file is truncated, has a bad checksum, or is missing entirely after a crash. In a data-pipeline context this manifests as replication lag spiking to infinity: ADF copy activities against the replica return stale rows, Power BI Direct Query reports freeze on yesterday's data, and any CDC-based pipeline that treats the replica as its source stops advancing.

Common causes

1Disk write failure during relay log rotation: the OS flushed a partial block to disk (e.g. during a RAID rebuild or NVMe controller reset), leaving the active relay log with a truncated or zero-padded tail that the SQL thread cannot parse.
2Unclean replica shutdown (OOM kill, power loss, `kill -9` on mysqld) while the SQL thread was mid-event: the relay log index file records a log that was never fully written, so on restart MySQL tries to open a file that ends at an unexpected byte offset.
3Relay log index out of sync: someone manually deleted relay log files from disk (e.g. to free space) without running `PURGE RELAYLOG` — the index still references files that no longer exist, causing an immediate read failure on the next SQL thread cycle.
4Incompatible relay log format after an in-place upgrade: upgrading the replica from MySQL 5.7 to 8.0 without resetting replication can leave relay logs written in the old binary log event format; the 8.0 SQL thread rejects events it cannot decode.
5Network filesystem latency (NFS, EFS, Azure Files) causing relay log writes to be buffered in the client cache but not yet visible on the OS read path — the SQL thread reads a stale inode size and interprets the gap as corruption.
6Checksum mismatch when `binlog_checksum` differs between primary and replica: if the primary emits CRC32-checksummed events and the replica's `slave_sql_verify_checksum` sees a relay log written by a different primary (e.g. after a failover), the checksums will fail verification and trigger 1594.
7Relay log filled the partition to 100%: `relay_log_space_limit` was not set, the partition ran out of inodes or bytes, and the partial write that was in progress at the moment of exhaustion left the file unreadable.

How to fix it

1Step 1 — Capture current replication state before touching anything: `SHOW SLAVE STATUS\G` — note `Relay_Log_File`, `Relay_Log_Pos`, `Master_Log_File`, `Exec_Master_Log_Pos`, and the full error text in `Last_SQL_Error`. Save this output; you will need the master log coordinates in step 4.
2Step 2 — Stop the replica threads cleanly: `STOP SLAVE;` (MySQL 5.7) or `STOP REPLICA;` (MySQL 8.0+). Do not skip this step — resetting a running replica can corrupt the relay log index further.
3Step 3 — Reset all relay logs: `RESET SLAVE;` (5.7) or `RESET REPLICA;` (8.0). This deletes all relay log files on disk and clears the relay log index. The replication credentials and master coordinates in `master.info` / `mysql.slave_master_info` are preserved unless you add `ALL`.
4Step 4 — Re-point the replica to the primary using the master coordinates from step 1: `CHANGE MASTER TO MASTER_HOST='primary_host', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='...', MASTER_LOG_FILE='binlog.000123', MASTER_LOG_POS=4567890;` — use `Exec_Master_Log_Pos` (not `Read_Master_Log_Pos`) as the position to avoid replaying already-applied transactions.
5Step 5 — Enable automatic relay log recovery to prevent recurrence: add `relay_log_recovery = ON` to the `[mysqld]` section of `/etc/mysql/my.cnf` (or `/etc/my.cnf`). With this setting, MySQL automatically discards and re-fetches relay log contents from the primary on every replica restart, bypassing any on-disk corruption.
6Step 6 — Start replication and verify: `START SLAVE;` then immediately run `SHOW SLAVE STATUS\G` — confirm `Slave_IO_Running: Yes`, `Slave_SQL_Running: Yes`, and watch `Seconds_Behind_Master` trending down toward 0. If `Last_SQL_Error` still shows 1594, the relay log written in this session is also corrupted, indicating a deeper disk problem; inspect `dmesg` and SMART data.
7Step 7 — If the replica has diverged or the required binlog position is no longer on the primary (purged): take a fresh snapshot from the primary (e.g. `mysqldump --single-transaction --master-data=2` or Percona XtraBackup), restore it on the replica, and bootstrap replication from the `CHANGE MASTER TO` coordinates embedded in the dump header.

Example log output

2026-05-11T03:14:22.841Z [ERROR] Slave SQL: Error 'Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
2026-05-11T03:14:22.841Z [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'relay-bin.000047' position 18349021.

Frequently asked questions

MySQL error 1594 fix — what is the fastest recovery path?

Run STOP SLAVE; RESET SLAVE; then CHANGE MASTER TO with the coordinates from Exec_Master_Log_Pos in SHOW SLAVE STATUS, and START SLAVE. This takes under a minute if the primary's binlog still covers the required position. If the binlog has been purged, you need a fresh snapshot from the primary before you can restart replication.

Will RESET SLAVE lose data?

RESET SLAVE (without ALL) deletes relay log files and clears the SQL thread's position, but it does not touch the primary or any already-applied transactions on the replica. Transactions that were fetched into the relay log but not yet applied will be re-fetched from the primary's binlog, so no committed primary data is lost — but any work done exclusively on the replica since the last sync will remain.

What does relay_log_recovery=ON actually do and when should I not use it?

On replica startup, MySQL discards all relay logs and re-fetches events from the primary starting at the last executed position, bypassing any on-disk relay log state. The one scenario where you should not use it is with multi-source replication (CHANGE MASTER TO FOR CHANNEL) on MySQL 5.7 — in that version relay_log_recovery has known issues with channel-specific relay log index files. On MySQL 8.0 multi-source it is safe.

Can 1594 happen during a failover to a new primary?

Yes — if you point the replica at a new primary (e.g. after a ProxySQL or orchestrator-driven failover) and the new primary has a different server_uuid or its binlog history diverges from what the relay log recorded, the SQL thread may hit a checksum or position mismatch that surfaces as 1594. The fix is the same: RESET SLAVE and CHANGE MASTER TO the new primary's current binlog position, or use GTID-based replication so the replica can self-position automatically.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html