快捷導(dǎo)航

MySQL slave_net_timeout參數(shù)解決的一個集群問題案例

更新時間：2015年05月29日 10:45:28 投稿：junjie

這篇文章主要介紹了MySQL slave_net_timeout參數(shù)解決的一個集群問題案例,問題日志請見正文,本文使用slave_net_timeout參數(shù)解決了這個問題,需要的朋友可以參考下

【背景】
對一套數(shù)據(jù)庫集群進行5.5升級到5.6之后,alter.log 報warning異常。

2015-02-03 15:44:51 19633 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the \'START SLAVE Syntax\' in the MySQL Manual for more information.

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

2 MySQL Replication的重連機制

在一個已經(jīng)建立主從復(fù)制關(guān)系的系統(tǒng)里面,正常情況下,由從庫向主庫發(fā)送一個 COM_BINLOG_DUMP 命令后,主庫有新的binlog event，會向備庫發(fā)送binlog。但是由于網(wǎng)絡(luò)故障或者其他原因?qū)е轮鲙炫c從庫的連接斷開或者主庫長時間沒有向從庫發(fā)送binlog。例如該例子中數(shù)據(jù)庫集群 10s 左右還沒有寫入的情況，超過slave_net_timeout設(shè)置的4s ，從庫會向主庫發(fā)起重連請求。5.6 版本slave 發(fā)起重連請求時，MySQL都會判斷有沒有用明文的用戶名密碼,如果有則發(fā)出上述信息到error.log。

【解決方法】
在本案例中可以嘗試將slave_net_timeout 調(diào)整大一些設(shè)置為25 。slave_net_timeout是設(shè)置在多少秒沒收到主庫傳來的Binary Logs events之后,從庫認(rèn)為網(wǎng)絡(luò)超時,Slave IO線程會重新連接主庫。該參數(shù)的默認(rèn)值是3600s ，然而時間太久會造成數(shù)據(jù)庫延遲或者主備庫直接的鏈接異常不能及時發(fā)現(xiàn)。將 slave_net_timeout 設(shè)得很短會造成 Master 沒有數(shù)據(jù)更新時頻繁重連。一般線上設(shè)置為5s 。

復(fù)制代碼代碼如下:

set global slave_net_timeout = 25

當(dāng)然也可以和業(yè)務(wù)方溝通，對于幾乎沒有訪問量的業(yè)務(wù)線進行下線，為公司節(jié)省資源。

您可能感興趣的文章: