Re: "Could not parse relay log event entry." error on slave

[David Griffiths]

Thanks for the response.

We can't afford to lose information, and I don't like doing dangerous 
things.

I guess it's time to rebuild the slave.

David

Gleb Paharenko wrote:

>Hello.
>
>
>
>  
>
>>Other than rebuilding the slave from a backup of the master, is there
>>    
>>
>
>  
>
>>any way to get the replication backup up?
>>    
>>
>
>
>
>Have you tried to stop a slave and then start with SQL_SLAVE_SKIP_COUNTER = n,
>
>as suggested at:
>
>  http://dev.mysql.com/doc/mysql/en/replication-problems.html
>
>
>
>But if the replication starts succesfully, you'll lose some information
>
>(which can be critical). You may RESET the slave and then use a CHANGE
>
>MASTER statement to begin the replication with 889778259 bin-log position.
>
>However it is dangerous: if the slave SQL thread was in the middle of 
>
>replicating temporary tables when it was stopped, and RESET SLAVE  is issued,
>
>these replicated temporary tables are deleted on the slave. 
>
>
>
>
>
>
>
>David Griffiths <dgriffiths@stripped> wrote:
>
>  
>
>>We have a master-slave setup in production.
>>    
>>
>
>  
>
>
>  
>
>>The master is running on a dual-Opteron with SuSE 8 SLES.
>>    
>>
>
>  
>
>
>  
>
>>The slave is running on a dual Xeon with SuSE 9.
>>    
>>
>
>  
>
>
>  
>
>>Both run MySQL 4.0.20
>>    
>>
>
>  
>
>
>  
>
>>We recently moved our traffic database to the machine and started 
>>    
>>
>
>  
>
>>writing additional traffic (perhaps as much as 600,000 inserts/updates 
>>    
>>
>
>  
>
>>plus at least as many selects per day).
>>    
>>
>
>  
>
>
>  
>
>>We use Nagios to monitor the machines, and have gotten alerts that the 
>>    
>>
>
>  
>
>>slave is not responding (this started yesterday, which is our busiest day).
>>    
>>
>
>  
>
>
>  
>
>>This morning, the alert appeared again, but this time, there was an 
>>    
>>
>
>  
>
>>error in "show slave status"
>>    
>>
>
>  
>
>
>  
>
>>"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."
>>    
>>
>
>  
>
>
>  
>
>>I am running a "mysqlbinlog" on the current binary log on the slave, but 
>>    
>>
>
>  
>
>>it's a large file, and is still going.
>>    
>>
>
>  
>
>
>  
>
>>On the master, the binary-log-pos is 929084940. On the slave, it's way 
>>    
>>
>
>  
>
>>back at 889778259
>>    
>>
>
>  
>
>
>  
>
>>Other than rebuilding the slave from a backup of the master, is there 
>>    
>>
>
>  
>
>>any way to get the replication backup up?
>>    
>>
>
>  
>
>
>  
>
>>David
>>    
>>
>
>  
>
>
>
>
>  
>