收到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: