MySQL主从复制中断处理一例

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

 

 

Show slave status\G,提示中继日志损坏,按以往的作法，根据提示从新指定合适的日志文件以及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 slavestatus\G，同步已经恢复，正在应用中继日志，等同步完成以后，而后随机抽查几张表（有更新，可是不是更新太频繁的表，发现数据一致）

 

 

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

            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: