mysql從庫服務器down機報錯Could not parse relay log event entry怎么辦

這篇文章主要為大家展示了“mysql從庫服務器down機報錯Could not parse relay log event entry怎么辦”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“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怎么辦”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！