MySQL主从复制中断处理一例

收到mysql主从中断报警邮件，马上登上服务器查看，发现是中继日志损坏。 

Show slave statusG,提示中继日志损坏,按以往的做法，根据提示重新指定合适的日志文件以及pos点。

 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.

2.  从MySQL5.5.X版本开始，增加了relay_log_recovery参数，这个参数的作用是：当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这个参数是默认关闭的。做主从的时候没有开启这项参数。修改my.cnf，添加这两项。（skip-slave-start ，mysql服务启动跳过自动启动主从复制，以免产生新的问题）,relay_log_recovery不支持动态修改。所以修改配置文件，重启MySQL服务,启动主从复制线程

#####my.cnf加这两项                   
relay_log_recovery = 1 

######也可以从库启动的时候跳过自动启动slave，自己手工启动，方便检查主从问题

skip_slave_start = 1

###################### 

 

3.再查看Show slavestatusG，同步已经恢复，正在应用中继日志，等同步完成之后，然后随机抽查几张表（有更新，但是不是更新太频繁的表，发现数据一致）

 #########################################################

            Relay_Master_Log_File: mysql-bin.000642
            Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

##############################################

            Master_SSL_Key: 
            Seconds_Behind_Master: 0
            Master_SSL_Verify_Server_Cert: No
            Last_IO_Errno: 0
            Last_IO_Error: 
            Last_SQL_Errno: 0
            Last_SQL_Error: