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: