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

　　【背景】

　　對一套數據庫集群進行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.

　　數據庫業務壓力 qps

　　【分析】

　　1 主從復制信息 主機地址，端口，復制用戶，binlog 文件位置等信息是存儲在master.info中的， 5.6 版本在安全性上做了很多改善，不建議在執行change master的時候指定密碼。如果在搭建主從時制定密碼，5.6 MySQL 會提示上述warning信息。這也是該集群在5.5版本時不報錯的原因。

　　2 MySQL Replication的重連機制

　　在一個已經建立主從復制關系的系統里面,正常情況下,由從庫向主庫發送一個 COM_BINLOG_DUMP 命令后,主庫有新的binlog event，會向備庫發送binlog。但是由于網絡故障或者其他原因導致主庫與從庫的連接斷開或者主庫長時間沒有向從庫發送binlog。例如該例子中數據庫集群 10s 左右還沒有寫入的情況，超過slave_net_timeout設置的4s ，從庫會向主庫發起重連請求。5.6 版本slave 發起重連請求時，MySQL都會判斷有沒有用明文的用戶名密碼,如果有則發出上述信息到error.log。

　　【解決方法】

　　在本案例中可以嘗試將slave_net_timeout 調整大一些 設置為25 。slave_net_timeout是設置在多少秒沒收到主庫傳來的Binary Logs events之后,從庫認為網絡超時,Slave IO線程會重新連接主庫。該參數的默認值是3600s ，然而時間太久會造成數據庫延遲或者主備庫直接的鏈接異常不能及時發現。將 slave_net_timeout 設得很短會造成 Master 沒有數據更新時頻繁重連。一般線上設置為5s 。

　　復制代碼 代碼如下:

　　set global slave_net_timeout = 25

　　當然也可以和業務方溝通，對于幾乎沒有訪問量的業務線進行下線 ，為公司節省資源