在Mysql中maxallowedpacket限制導(dǎo)致主從同步出錯

2024-07-24 12:35:31

字體：大中小

供稿：網(wǎng)友

　　主從同步功能多任用于多臺服務(wù)器之間數(shù)據(jù)的一個傳輸了,在此小編今天主來為各位介紹一篇在max_allowed_packet限制導(dǎo)致主從同步出錯問題解決方法.

　　Mysql主從運行有一段時間了,沒有出過什么問題,但最近接著出了兩次問題,記錄下方便后面排查.

　　Slave_IO_Running和Slave_SQL_Running均為YES,主從同步出錯.

　　首先還是確認(rèn)下各服務(wù)器狀態(tài),查看主庫狀態(tài)正常,binlog position一直在變,進(jìn)程狀態(tài)也正常.

　　查看重庫狀態(tài),整體上看重庫只是有延遲.

　　mysql> show slave status/G;
　　
　　Master_Log_File: mysql-bin.000364
　　
　　Read_Master_Log_Pos: 246924389
　　
　　Relay_Log_File: mysql-relay-bin.3831269
　　
　　Relay_Log_Pos: 244389572
　　
　　Relay_Master_Log_File: mysql-bin.000363
　　
　　Slave_IO_Running: Yes
　　
　　Slave_SQL_Running: Yes
　　
　　Seconds_Behind_Master: 23423
　　
　　mysql> show processlist;
　　
　　+---------+-------+-----------------------------------------------------------------------------+------------------+
　　
　　| Command | Time | State                                                                       | Info             |
　　
　　+---------+-------+-----------------------------------------------------------------------------+------------------+
　　
　　| Connect | 22800 | Waiting for master to send event                                            | NULL             |
　　
　　| Connect |    99 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |
　　
　　+---------+-------+-----------------------------------------------------------------------------+------------------+
　　但等一段時間查看重庫卻一直不更新,重啟后Seconds_Behind_Master為0,Slave_IO_Running和Slave_SQL_Running狀態(tài)均為YES,確認(rèn)了Master_Host、Master_User等參數(shù),也匹配了Master_Server_Id都是正常的,在網(wǎng)上也查到了SQL_SLAVE_SKIP_COUNTER來跳過一步操作,但因為對數(shù)據(jù)完整性要求比較高,擔(dān)心產(chǎn)生數(shù)據(jù)異常而不敢操作,于是到此基本上就沒轍了.

　　等一天還找不到就打算重做了,但重做也不是辦法,總得找到問題,數(shù)據(jù)比較多也不可能每次去重做,之前查看過Binlog沒有明顯發(fā)現(xiàn),于是還是得再去查看下Binlog看能不能發(fā)現(xiàn)什么？

　　mysqlbinlog mysql-relay-bin.3831269 --start-position=244389572 --stop-position=246924461 | more
　　
　　mysqlbinlog mysql-relay-bin.3831269 --start-datetime="2014-08-07 21:30:00" --stop-datetime="2014-08-07 21:35:00" --base64-output=decode-rows -v | more
　　binlog基于行的復(fù)制帶上了--base64-output=decode-rows -v參數(shù).

　　慢慢的還真的發(fā)現(xiàn)了點東西,發(fā)現(xiàn)有執(zhí)行很多的刪除語句,當(dāng)通過wc統(tǒng)計時發(fā)現(xiàn)竟然有70多萬,在通過業(yè)務(wù)查看是有執(zhí)行一條SQL,刪除表中的所有記錄,數(shù)據(jù)太多,此時查看主從這個表的記錄,主庫為空,重庫記錄全在,那可能就是這個原因?qū)е碌?該操作可以跳過,于是嘗試跳過之:

　　max_allowed_packet

　　mysql 服務(wù)是通過網(wǎng)絡(luò)包來傳輸數(shù)據(jù)的(通信信息包是指發(fā)送至MySQL服務(wù)器的單個SQL語句或發(fā)送至客戶端的單一行),mysql協(xié)議能夠識別的數(shù)據(jù)包的大小是由max_allowed_packet控制的。當(dāng)MySQL客戶端或mysqld服務(wù)器收到大于max_allowed_packet字節(jié)的信息包時,將發(fā)出“log event entry exceeded max_allowed_packet;”錯誤,并關(guān)閉連接。就像此次主從復(fù)制遇到的，IO 進(jìn)程從主庫獲取日志，但是單個日志中的sql 大小超過了max_allowed_packet的限制，于是報錯,IO thread 進(jìn)程停止,sql thread 顯示為yes,對于客戶端,如果通信信息包過大,在執(zhí)行查詢期間,可能會遇到“丟失與MySQL服務(wù)器的連接”錯誤.

　　停止重庫,主從都調(diào)整下,然后啟動重庫即可.

　　stop slave;
　　
　　set global max_allowed_packet=1035543552;
　　
　　start slave;。

（編輯：武林網(wǎng)）

上一篇：mysql數(shù)據(jù)庫explain命令用法細(xì)解

下一篇：Mysql慢查詢使用及參數(shù)詳解