《Mysql入門(mén)MySQL slave_net_timeout參數(shù)解決的一個(gè)集群?jiǎn)栴}案例》要點(diǎn)：
本文介紹了Mysql入門(mén)MySQL slave_net_timeout參數(shù)解決的一個(gè)集群?jiǎn)栴}案例，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

MYSQL入門(mén)【背景】
?? 對(duì)一套數(shù)據(jù)庫(kù)集群進(jìn)行5.5升級(jí)到5.6之后,alter.log 報(bào)warning異常.
??

數(shù)據(jù)庫(kù)業(yè)務(wù)壓力? qps 1 tps 幾乎為0? 4-10 秒或者更久會(huì)有寫(xiě)入操作.
【分析】
? 1 主從復(fù)制信息 主機(jī)地址,端口,復(fù)制用戶,binlog 文件位置等信息是存儲(chǔ)在master.info中的, 5.6 版本在安全性上做了很多改善,不建議在執(zhí)行change master的時(shí)候指定密碼.如果在搭建主從時(shí)制定密碼,5.6 MySQL 會(huì)提示上述warning信息.這也是該集群在5.5版本時(shí)不報(bào)錯(cuò)的原因.
?
? 2 MySQL Replication的重連機(jī)制

MYSQL入門(mén)? 在一個(gè)已經(jīng)建立主從復(fù)制關(guān)系的系統(tǒng)里面,正常情況下,由從庫(kù)向主庫(kù)發(fā)送一個(gè) COM_BINLOG_DUMP 命令后,主庫(kù)有新的binlog event,會(huì)向備庫(kù)發(fā)送binlog.但是由于網(wǎng)絡(luò)故障或者其他原因?qū)е轮鲙?kù)與從庫(kù)的連接斷開(kāi)或者主庫(kù)長(zhǎng)時(shí)間沒(méi)有向從庫(kù)發(fā)送binlog.例如該例子中數(shù)據(jù)庫(kù)集群 10s 左右還沒(méi)有寫(xiě)入的情況,超過(guò)slave_net_timeout設(shè)置的4s ,從庫(kù)會(huì)向主庫(kù)發(fā)起重連請(qǐng)求.5.6 版本slave 發(fā)起重連請(qǐng)求時(shí),MySQL都會(huì)判斷有沒(méi)有用明文的用戶名密碼,如果有則發(fā)出上述信息到error.log.
?
【解決方法】
?? 在本案例中可以嘗試將slave_net_timeout 調(diào)整大一些 設(shè)置為25 .slave_net_timeout是設(shè)置在多少秒沒(méi)收到主庫(kù)傳來(lái)的Binary Logs events之后,從庫(kù)認(rèn)為網(wǎng)絡(luò)超時(shí),Slave IO線程會(huì)重新連接主庫(kù).該參數(shù)的默認(rèn)值是3600s ,然而時(shí)間太久會(huì)造成數(shù)據(jù)庫(kù)延遲或者主備庫(kù)直接的鏈接異常不能及時(shí)發(fā)現(xiàn).將 slave_net_timeout 設(shè)得很短會(huì)造成 Master 沒(méi)有數(shù)據(jù)更新時(shí)頻繁重連.一般線上設(shè)置為5s .

??? 當(dāng)然也可以和業(yè)務(wù)方溝通,對(duì)于幾乎沒(méi)有訪問(wèn)量的業(yè)務(wù)線進(jìn)行下線 ,為公司節(jié)省資源.

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/5474.html