MySQL5.1主從同步出現Relay log read failure錯誤解決方法，mysql5.1relay

MySQL5.1主從同步出現Relay log read failure錯誤解決方法，mysql5.1relay

眾所周知MySQL5.1的Replication是比較爛的。MySQL的每一個版本更新關於同步方面每次都是可以看到一大堆。但MySQL 5.1性能是比較突出的。所以經不住誘惑使用MySQL 5.1。所以也要經常遇到一些Bug。如：
復制代碼 代碼如下:
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.118
                  Master_User: repl_wu
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: mysql-bin.005121
          Read_Master_Log_Pos: 64337286
               Relay_Log_File: relay-bin.003995
                Relay_Log_Pos: 18446697137031827760
        Relay_Master_Log_File: mysql-bin.005121
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: 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.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4
              Relay_Log_Space: 64337901
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: 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.
1 row in set (0.00 sec)

從上面可以看到是中繼日值或是Master上的日值出問題了。

首先如果是中繼日值壞掉，那只需要找到同步的時間點，然後重新同步，這樣就可以有新的中繼日值了。如果Master上的日值壞了就麻煩了。

從經驗來看，這是中繼日值出問題了。處理方法：

需要找到同步的點。

日值為：Master_Log_File: mysql-bin.005121，Relay_Master_Log_File: mysql-bin.005121以Relay_Master_Log_File為准，Master_Log_File為參考。

日值執行時間點：
復制代碼 代碼如下:Exec_Master_Log_Pos: 4

那麼現在就可以：
復制代碼 代碼如下:
mysql>stop slave;
 
mysql>change master to Master_Log_File='mysql-bin.005121', Master_Log_Pos=4;
  
mysql>start slave;
 
mysql>show slave status\G;

進行確認。

建議：

在使用MySQL-5.1.36以下的版本的同學，請盡快升級到MySQL-5.1.40 & MySQL-5.1.37sp1

mysql怎實現主從同步數據庫備份？

1.主服務器：
#Master start
　　 log-bin="d:/log/mysql/mysql_log_bin"
　　server-id=1
　　　#Master end
　　2.從服務器：
#Slave start
log-bin="D:/log/mysql2/log-bin.log"
relay_log="D:/log/mysql2/relay-log-bin"
#從機id，區別於主機id
server-id=2
#主機ip，供從機連接主機用
#master-host=localhost
#主機端口
#master-port=3300
#剛才為從機復制主機數據新建的賬號
#master-user=slave
#剛才為從機復制主機數據新建的密碼
#master-password=654321
#重試間隔時間10秒
#master-connect-retry=10
#需要同步的數據庫
#replicate-do-db=test
#啟用從庫日志，這樣可以進行鏈式復制
log-slave-updates
#從庫是否只讀，0表示可讀寫，1表示只讀
read-only=1

#只復制某個表
#replicate-do-table=tablename
#只復制某些表（可用匹配符）
#replicate-wild-do-table=tablename%
#只復制某個庫
#replicate-do-db=dbname
#不復制某個表
#replicate-ignore-table=tablename
#不復制某些表
#replicate-wild-ignore-table=tablename%
#不復制某個庫
#replicate-ignore-db=dbname
#Slave end
3.對從服務器制定主服務器使用CHANGE MASTER 語句
注意：1.一定要在主服務器上創建一個可以執行replication的用戶
2.該用戶名在從服務器上可遠程登錄到主服務器。
3.開啟MySQL的log-bin日志功能
參考資料：blog.163.com/...31959/
 

怎檢查MySQL數據庫的主從延時？

MySQL數據庫主從延時如何去判斷呢？本文我們介紹了兩種判斷方法：1. Seconds_Behind_Master vs 2. mk-heartbeat，接下來我們就分別介紹這些內容。 日常工作中，對於MySQL主從復制檢查，一方面我們要保證復制的整體結構是否正常，另一方面需要檢查主從數據是否保持一致。對於前者我們可以通過監控復制線程是否工作正常以及主從延時是否在容忍范圍內，對於後者則可以通過分別校驗主從表中數據的md5碼是否一致，來保證數據一致，可以使用Maatkit工具包中的mk-table- checksum工具去檢查。 方法1： 通過監控show slave status\G命令輸出的Seconds_Behind_Master參數的值來判斷，是否有發生主從延時。其值有這麼幾種： NULL — 表示io_thread或是sql_thread有任何一個發生故障，也就是該線程的Running狀態是No，而非Yes。 0 — 該值為零，是我們極為渴望看到的情況，表示主從復制良好，可以認為lag不存在。 正值— 表示主從已經出現延時，數字越大表示從庫落後主庫越多。 負值— 幾乎很少見，我只是聽一些資深的DBA說見過，其實，這是一個BUG值，該參數是不支持負值的，也就是不應該出現。 show slave status\G，該命令的輸出結果非常豐厚，給我們的監控提供了很多有意義的參數，比如：Slave_IO_Running該參數可作為 io_thread的監控項，Yes表示io_thread的和主庫連接正常並能實施復制工作，No則說明與主庫通訊異常，多數情況是由主從間網絡引起的問題；Slave_SQL_Running該參數代表sql_thread是否正常，具體就是語句是否執行通過，常會遇到主鍵重復或是某個表不存在。下面就說到今天的重點Seconds_Behind_Master，該值作為判斷主從延時的指標，那麼它又是怎麼得到這個值的呢，同時，它為什麼又受到很多人的質疑？ Seconds_Behind_Master是通過比較sql_thread執行的event的timestamp和 io_thread復制好的event的timestamp（簡寫為ts）進行比較，而得到的這麼一個差值。我們都知道的relay-log和主庫的 bin-log裡面的內容完全一樣，在記錄sql語句的同時會被記錄上當時的ts，所以比較參考的值來自於binlog，其實主從沒有必要與NTP進行同步，也就是說無需保證主從時鐘的一致。 你也會發現，其實比較真正是發生在io_thread與sql_thread之間，而io_thread才真正與主庫有關聯，於是，問題就出來了，當主庫I/O負載很大或是網絡阻塞，io_thread不能及時復制binlog（沒有中斷，也在復制），而 sql_thread一直都能跟上io_thread的腳本，這時Seconds_Behind_Master的值是0，也就是我們認為的無延時，但是，實際上不是，你懂得。這也就是為什麼大家要批判用這個參數來監控數據庫是否發生延時不准的原因，但是這個值並不是總是不准，如果當io_thread與 master網絡很好的情況下，那麼該值也是很有價值的。 之前，提到Seconds_Behind_Master這個參數會有負值出現，我們已經知道該值是io_thread的最近跟新的ts與sql_thread執行到的ts差值，前者始終是大於後者的，唯一的肯能就是某個event的ts發生了錯誤，比之前的小了，那麼當這種情況......余下全文>>