共計 9575 個字符，預計需要花費 24 分鐘才能閱讀完成。

行業資訊    
數據庫    
MySQL 數據庫    
mysql 從庫服務器 down 機報錯 Could not parse relay log event entry 怎么辦

這篇文章主要為大家展示了“mysql 從庫服務器 down 機報錯 Could not parse relay log event entry 怎么辦”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“mysql 從庫服務器 down 機報錯 Could not parse relay log event entry 怎么辦”這篇文章吧。

環境介紹：

最近網站總是出問題，因為 play 服務總是跑著跑著就死了，于是經理嘗試把 play 跑在我的 mysql 這兩臺服務器上（因為這兩臺服務器的資源很空閑），可是沒想到才跑了半天，就把服務器的 128G 內存耗盡，服務器無法正常使用，輸入任何命令都報錯，無法分配內存，reboot 都不可以，只能去機房強制關機了。。。

我這里一兩臺，主主復制的 mysql：

192.10.0.143

192.10.0.144

通過 keepalived 映射出來了 vip:192.10.0.145，目前 vip 在 144 上。

重啟的是 143.

啟動之后，mysql 服務成功開啟了，可是主從狀態報錯，sql 進程狀態為 NO, 如下：

MariaDB [(none)] show slave status\G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.144

Master_User: info_syncer

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000823

Read_Master_Log_Pos: 60049919

Relay_Log_File: mysql-relay-bin.000047

Relay_Log_Pos: 268334387

Relay_Master_Log_File: mysql-bin.000822

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: 268334100

Relay_Log_Space: 535066509

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.

Replicate_Ignore_Server_Ids:

Master_Server_Id: 2

Master_SSL_Crl:

Master_SSL_Crlpath:

Using_Gtid: No

Gtid_IO_Pos:

1 row in set (0.00 sec)

ERROR: No query specified

報錯原因：

從上面紅體字可以知道，由于從庫的異常關機，導致接收的主庫的二進制日志崩潰，進而導致從庫的 relay 日志損壞，sql 進程無法讀取，導致從庫的 sql 進程狀態為：NO。

問題解決：

MariaDB [(none)] stop slave ;

Query OK, 0 rows affected (0.00 sec)

解決方法一： 

找到，第一行記錄了當前正在執行的 log-relay 文件名  

找到該文件的下一個文件  

使用 mysqlbinlog 查看該文件，在 #98 這行有 Rotate to log-bin.000004 pos: 4 等信息，這就是目前 slave 停止的位置  ，或者

在 slave 上重新指定同步位置，重新執行：

change master to 

master_host= 1.1.1.1 ,

master_user= repl ,

master_password= 111111 ,

master_port=3306,

master_log_file= log-bin.000004 ,

master_log_pos=4;

然后啟動 slave，

start slave ;

解決方法二：

stop slave 之后，重新 reset slave;

查看 slave 狀態，正常了。。。。。

reset slave 到底做了什么？？

RESET SLAVE

官方的解釋如下

1）RESET SLAVE makes the slave forget its replication position in the master s binary log. This statement is meant to be used for a clean start: It clears the master info and relay log info repositories, deletes all the relay log files, and starts a new relay log file. It also resets to 0 the replication delay specified with the MASTER_DELAY option to CHANGE MASTER TO. To use RESET SLAVE, the slave replication threads must be stopped (use STOP SLAVE if necessary).

2）RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. This means that START SLAVE can be issued without requiring a CHANGE MASTER TO statement following

reset slave

其實，它是直接刪除 master.info 和 relay-log.info 文件，并刪除所有的 relay log，然后重新生成一個新的 relay log，即使 relay log 中還有 SQL 沒有被 SQL 線程 apply 完。

但是 RESET SLAVE 有個問題，它雖然刪除了上述文件，但內存中的 change master 信息并沒有刪除，此時，可直接執行 start slave，但因為刪除了 master.info 和 relay-log.info，它會從頭開始接受主的 binlog 并應用。(注意：這里所說的從頭是說：reset 的時候，正在接受的主的 binlog, 從新接受這個 binlog). 如果 SQL thread 正在復制臨時表的過程中，執行了 stop slave，并且執行了 reset slave，這些被復制的臨時表將被刪除。

題外話：reset master 做了什么？

1. reset master 將刪除日志索引文件中記錄的所有 binlog 文件，創建一個新的日志文件 起始值從 000001 開始，

2. reset master 不能用于有任何 slave 正在運行的主從關系的主庫。因為在 slave 運行時刻 reset master 命令不被支持，reset master 將 master 的 binlog 從 000001 開始記錄,slave 記錄的 master log 則是 reset master 時主庫的最新的 binlog, 從庫會報錯無法找的指定的 binlog 文件。

繼續解決問題：

主從狀態正常后，查看告警日志，發現報錯

告警日志報錯：表 crashed，需要 repaire

ERROR] log.logs: 1 client is using or hasn t closed the table properly

170310 11:54:14 [ERROR] mysqld: Table ./log/oprlogs is marked as crashed and should be repaired

170310 11:54:14 [Warning] Checking table:   ./log/oprlogs

170310 11:54:14 [ERROR] log.oprlogs: 1 client is using or hasn t closed the table properly

170310 11:54:14 [ERROR] log.oprlogs: Size of datafile is: 1656831165       Should be: 1656830670

170310 11:54:47 [ERROR] log.oprlogs: Found 495 deleted space.   Should be 0

170310 11:54:47 [ERROR] log.oprlogs: Found 15 deleted blocks       Should be: 0

170310 11:54:47 [ERROR] log.oprlogs: Found 50207005 key parts. Should be: 50206990

170310 11:54:47 [ERROR] mysqld: Table ./log/history is marked as crashed and should be repaired

170310 11:54:47 [Warning] Checking table:   ./log/history

170310 11:54:47 [ERROR] log.history: 1 client is using or hasn t closed the table properly

直接 repair table table_name 就可以了。。。。，依次修復日志中出現的被標記為 crashed 的表。

MariaDB [(none)] repair  table  log.logs;

下面講下修復 table：整理自網絡。。。。。

多數情況下, 數據庫被破壞只是指索引文件受到了破壞, 真正的數據被破壞掉的情況非常少。大多數形式的數據庫破壞的的修復相當簡單。

和前面的校驗一樣, 修復的方式也有三種。

下面講的方法只對 MyISAM 格式的表有效。其他類型的損壞需要從備份中恢復。

1,REPAIR TABLE SQL statement(mysql 服務必須處于運行狀態)。

2, 命令 mysqlcheck(mysql 服務可以處于運行狀態)。

3, 命令 myisamchk(必須停掉 mysql 服務, 或者所操作的表處于不活動狀態)。

在修復表的時候, 最好先作一下備份。所以你需要兩倍于原始表大小的硬盤空間。請確保在進行修復前你的硬盤空間還沒有用完。

1 用”repair table”方式修復

語法:repair table 表名 [選項]

選項如下:

QUICK 用在數據表還沒被修改的情況下, 速度最快

EXTENDED 試圖去恢復每個數據行, 會產生一些垃圾數據行, 萬般無奈的情況下用

USE_FRM 用在.MYI 文件丟失或者頭部受到破壞的情況下。利用.frm 的定義來重建索引

多數情況下, 簡單得用”repair table tablename”不加選項就可以搞定問題。但是當.MYI 文件丟失或者頭部受到破壞時, 這樣的方式不管用, 例如:

mysql REPAIR TABLE mytable;

+————————-+——–+———-+———————————————+

| Table | Op | Msg_type | Msg_text |

+————————-+——–+———-+———————————————+

| sports_results.mytable | repair | error | Can’t find file:‘mytable.MYI’(errno: 2) |

+————————-+——–+———-+———————————————+

修復失敗的原因時索引文件丟失或者其頭部遭到了破壞, 為了利用相關定義文件來修復, 需要用 USE_FRM 選項。例如:

mysql REPAIR TABLE mytable USE_FRM;

+————————-+——–+———-+————————————+

| Table | Op | Msg_type | Msg_text |

+————————-+——–+———-+————————————+

| sports_results.mytable | repair | warning | Number of rows changed from 0 to 2 |

| sports_results.mytable | repair | status | OK |

+————————-+——–+———-+————————————+

我們可以看到 Msg_test 表項的輸出信息”ok”, 表名已經成功修復受損表。

2 用 mysql 內建命令 mysqlcheck 來修復

當 mysql 服務在運行時, 也可以用 mysql 內建命令 mysqlcheck 來修復。

語法:mysqlcheck -r 數據庫名 表名 -uuser -ppass

%mysqlcheck -r sports_results mytable -uuser -ppass

sports_results.mytable OK

利用 mysqlcheck 可以一次性修復多個表。只要在數據庫名后列出相應表名即可 (用空格隔開)。或者數據庫名后不加表名, 將會修復數據庫中的所有表, 例如:

%mysqlcheck -r sports_results mytable events -uuser -ppass

sports_results.mytable OK

sports_results.events OK

%mysqlcheck -r sports_results -uuser -ppass

sports_results.mytable OK

sports_results.events OK

3 用 myisamchk 修復

用這種方式時,mysql 服務必須停掉, 或者所操作的表處于不活動狀態 (選項 skip-external-locking 沒被使用)。記著一定要在相關.MYI 文件的路徑下或者自己定義其路徑。

語法:myisamchk [選項] [表名]

下面是其選項和描述

–backup, -B 在進行修復前作相關表得備份

–correct-checksum 糾正校驗和

–data-file-length=#, -D # 重建表時, 指定數據文件得最大長度

–extend-check, -e 試圖去恢復每個數據行, 會產生一些垃圾數據行, 萬般無奈的情況下用

–force, -f 當遇到文件名相同的.TMD 文件時, 將其覆蓋掉。

keys-used=#, -k # 指定所用的 keys 可加快處理速度, 每個二進制位代表一個 key. 第一個 key 為 0

–recover, -r 最常用的選項, 大多數破壞都可以通過它來修復。如果你的內存足夠大, 可以增大參數 sort_buffer_size 的值來加快恢復的速度。但是遇到唯一鍵由于破壞而不唯一 的表時, 這種方式不管用。

–safe-recover -o 最徹底的修復方式, 但是比 - r 方式慢, 一般在 - r 修復失敗后才使用。這種方式讀出 所有的行, 并以行為基礎來重建索引。它的硬盤空間需求比 - r 方式稍微小一點, 因 為它沒創建分類緩存。你可以增加 key_buffer_size 的值來加快修復的速度。

–sort-recover, -n mysql 用它類分類索引, 盡管結果是臨時文件會非常大

–character-sets-dir=… 包含字符集設置的目錄

–set-character-set=name 為索引定義一個新的字符集

–tmpdir=path, -t 如果你不想用環境變量 TMPDIR 的值的話, 可以自定義臨時文件的存放位置

–quick, -q 最快的修復方式, 當數據文件沒有被修改時用, 當存在多鍵時, 第二個 - q 將會修改 數據文件

–unpack, -u 解開被 myisampack 打包的文件

myisamchk 應用的一個例子

% myisamchk -r mytable

– recovering (with keycache) MyISAM-table‘mytable.MYI’

題外引申。。。

REPAIR TABLE `table_name` 修復表  

OPTIMIZE TABLE `table_name` 優化表  

REPAIR TABLE 語句被寫入二進制日志中，除非使用了自選的 NO_WRITE_TO_BINLOG 關鍵詞（或其別名 LOCAL）。

REPAIR TABLE 用于修復被破壞的表。 

OPTIMIZE TABLE 用于回收閑置的數據庫空間，當表上的數據行被刪除時，所占據的磁盤空間并沒有立即被回收，使用了 OPTIMIZE TABLE 命令后這些空間將被回收，并且對磁盤上的數據行進行重排（注意：是磁盤上，而非數據庫）。  多數時間并不需要運行 OPTIMIZE TABLE，只需在批量刪除數據行之后，或定期（每周一次或每月一次）進行一次數據表優化操作即可，只對那些特定的表運行。

從新 chang 的日志位置和日志號

無論是新搭建主從復制，還是

在拷貝之前要先鎖定數據，然后再獲得相關的日志信息（FILE POSITION）：

mysql FLUSH TABLES WITH READ LOCK;         鎖表，一般新加主從的時候，保重一致性

MariaDB [log] SHOW MASTER STATUS;

+——————+———–+————–+————————–+

| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB         |

+——————+———–+————–+————————–+

| mysql-bin.000825 | 287366341 |              | mysql,information_schema |

+——————+———–+————–+————————–+

1 row in set (0.00 sec)

接下來拷貝數據文件時，如果是 MyISAM 表類型的話，直接拷貝即可；如果是 InnoDB 表類型的話，一定要先停止 MySQL 服務再拷貝，否則拷貝文件可能無法使用。把拷貝的數據文件直接復制到從服務器的數據目錄。

最后還需要再指定一下日志信息：

mysql CHANGE MASTER TO

MASTER_HOST= MASTER_HOST ,

MASTER_USER= SLAVE_USER ,

MASTER_PASSWORD= SLAVE_PASSWORD ,

MASTER_LOG_FILE= FILE ,

MASTER_LOG_POS= POSITION

在主服務器上直接拷貝數據文件雖然很快，但需要鎖表或者停止服務，這會影響線上服務。如果先前已經有了從服務器，那么可以用舊的從服務器做母本來克隆新的從服務器：

先在舊的從服務器上查詢日志信息：

mysql SHOW SLAVE STATUS;

我們需要的是其中的 Relay_Master_Log_File Exec_Master_Log_Pos。

然后在舊的從服務器上按照前面的方法得到數據，可以先 stop slave，然后拷貝數據并在新的從服務器上還原。

接著在新的從服務器上設置日志信息：

mysql CHANGE MASTER TO

MASTER_HOST= MASTER_HOST ,

MASTER_USER= SLAVE_USER ,

MASTER_PASSWORD= SLAVE_PASSWORD ,

MASTER_LOG_FILE= Relay_Master_Log_File ,

MASTER_LOG_POS= Exec_Master_Log_Pos

不管用那個方法，最后記得在從服務器上啟動復制，并檢查工作是否正常：

mysql START SLAVE;

mysql SHOW SLAVE STATUS;

注意：

MariaDB [(none)] show slave status\G;

顯示的 Master_Log_File 和 Read_Master_Log_Pos 這兩個只對應這 master

show master  status\G; 的文件號和位置

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.143

Master_User: info_syncer

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000019

Read_Master_Log_Pos: 1038

以上是“mysql 從庫服務器 down 機報錯 Could not parse relay log event entry 怎么辦”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！