Resolving MySQL Replication Failures Due to Corrupted Relay Binlogs

Resolving MySQL Replication Failures Due to Corrupted Relay Binlogs

Sometimes MySQL replication crashes due to corrupted relay binlogs (error 1594), and it is not possible to restart it with a simple START SLAVE command. Here is a step-by-step guide on how to resolve this issue.

Step 1: Check the Current Slave Status

To check the current slave status, execute the following command:

show slave status\G

You should see a result similar to this:

************************** 1. row ***************************

        Slave_IO_State: Waiting for master to send event
           Master_Host: 192.168.194.74
           Master_User: replicator
           Master_Port: 3306
         Connect_Retry: 60
       Master_Log_File: mysql-bin.001274
   Read_Master_Log_Pos: 1045327404
        Relay_Log_File: 3_dbbackup.003821
         Relay_Log_Pos: 617884398
 Relay_Master_Log_File: mysql-bin.001273
      Slave_IO_Running: Yes
     Slave_SQL_Running: No
        Replicate_Do_DB: 
    Replicate_Ignore_DB: 
     Replicate_Do_Table: 
 Replicate_Ignore_Table: 
 Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
          Last_Errno: 1594
          Last_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.
         Skip_Counter: 0
 Exec_Master_Log_Pos: 617884110
     Relay_Log_Space: 3192816253
     Until_Condition: None
      Until_Log_File: 
       Until_Log_Pos: 0
 Master_SSL_Allowed: No
 Master_SSL_CA_File: 
 Master_SSL_CA_Path: 
    Master_SSL_Cert: 
  Master_SSL_Cipher: 
     Master_SSL_Key: 
 Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
      Last_IO_Errno: 0
       Last_IO_Error: 
     Last_SQL_Errno: 1594
      Last_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.
Replicate_Ignore_Server_Ids: 
    Master_Server_Id: 13
     Master_SSL_Crl: 
 Master_SSL_Crlpath: 
         Using_Gtid: No
          Gtid_IO_Pos: 
Replicate_Do_Domain_Ids: 
Replicate_Ignore_Domain_Ids: 
       Parallel_Mode: conservative

Important values to note: Relay_Master_Log_File and Exec_Master_Log_Pos. You will need them to correctly restart replication on your slave.

Step 2: Restart Replication

To restart replication, execute the following commands (replace the file and position with your actual values):

STOP SLAVE;

RESET SLAVE;

CHANGE MASTER TO master_log_file='mysql-bin.001273', master_log_pos=617884110;

START SLAVE;

Warning: RESET SLAVE will remove all relay logs and replication settings. Ensure you have the correct values for master_log_file and master_log_pos before running this command.

Step 3: Verify Replication Status

To check if replication is working again, execute the command:

show slave status\G

Before considering your slave as synchronized, check the value of the Seconds_Behind_Master parameter from the status command. In our case, the value was (5187 seconds):

Seconds_Behind_Master: 5187

Within the next few minutes, replication was synchronized again with the master and replication lag became 0 seconds.

Seconds_Behind_Master: 0

This is the time when you can start using the MySQL slave again in production.

×