《MYSQL教程Mysql DNS反向解析導(dǎo)致連接超時過程分析(skip-name-resolve)》要點：
本文介紹了MYSQL教程Mysql DNS反向解析導(dǎo)致連接超時過程分析(skip-name-resolve)，希望對您有用。如果有疑問，可以聯(lián)系我們。
MYSQL數(shù)據(jù)庫設(shè)備在連接mysql時候,等待服務(wù)器的banner信息需要4s左右,影響了Mysql服務(wù)的連接速度.
通過如下方式進行驗證：
MYSQL數(shù)據(jù)庫1、Telnet端口驗證
MYSQL數(shù)據(jù)庫通過設(shè)備和虛擬機(Linux系統(tǒng))分別Telnet Mysql服務(wù)的端口,會出現(xiàn)一下現(xiàn)象：
MYSQL數(shù)據(jù)庫設(shè)備(UAG/SCANNER)： telnet后,等待Mysql的服務(wù)器端回應(yīng)大概需要等10s左右.
MYSQL數(shù)據(jù)庫[DPtech-Developer-Shell]telnet 10.101.0.206 3308
Trying 10.101.0.206...
Connected to 10.101.0.206.
Escape character is '^]'.
E
5.0.67-community-nt-log?Hc95
虛擬機(Ubuntu)：telnet后,立即得到了Mysql服務(wù)器的返回
MYSQL數(shù)據(jù)庫[root]~# telnet 10.101.0.206 3308
Trying 10.101.0.206...
Connected to 10.101.0.206.
Escape character is '^]'.
E
5.0.67-community-nt-log?D%(;1$]+,￠!Zdh`'?G)6r]YConnection closed by foreign host.?? //這里耗時很短
MYSQL數(shù)據(jù)庫2、通過程序進行驗證
MYSQL數(shù)據(jù)庫具體源代碼見附件：驗證程序源代碼
源代碼基本上是設(shè)置了Recv超時后,建立socket連接之后接受數(shù)據(jù),收到后計時并輸出.
MYSQL數(shù)據(jù)庫在設(shè)備上和虛擬機中的結(jié)果分別如下：
設(shè)備：
MYSQL數(shù)據(jù)庫[DPtech-Developer-Shell]/tcpclient_mips 10.101.0.1 3306
花費時間:19553
Recved 68 bytes
@
5.5.2-m2-community%uD3q`n)
MYSQL數(shù)據(jù)庫虛擬機：
MYSQL數(shù)據(jù)庫[root]tcp_demo# ./tcpclient 10.101.0.1 3306
花費時間：10525
Recved 68 bytes
@
5.5.2-m2-communitd~k~Y";B
MYSQL數(shù)據(jù)庫可以發(fā)現(xiàn),設(shè)備上大約比Linux服務(wù)器多耗時9s,其中10秒鐘可能是recv本身超時的時間.
MYSQL數(shù)據(jù)庫3、通過不同操作系統(tǒng)進行Telnet驗證
MYSQL數(shù)據(jù)庫通過Windows系統(tǒng)和Linux虛擬機、設(shè)備,分別通過Telnet進行連接嘗試,通過抓包分析得知,只有設(shè)備的耗時比較長,其他的耗時都比較短.
抓包時發(fā)現(xiàn)設(shè)備中的socket建立之后,MYSQL服務(wù)器需要發(fā)送很多次的NBNS報文后,才會傳輸banner信息,而Linux虛擬機和Windows系統(tǒng)的主機在這個過程中都沒有出現(xiàn)這個問題.
查找了一些資料,關(guān)于MYSQL NBNS報文的問題：
MYSQL數(shù)據(jù)庫Mysql論壇的提問：
MYSQL數(shù)據(jù)庫http://forums.mysql.com/read.php?11,250982,250982#msg-250982
該問題的答復(fù)
http://forums.mysql.com/read.php?11,250982,254683#msg-254683
從答復(fù)中來看,貌似是某些版本的問題,臨時的解決方案是對Mysql服務(wù)器進行配置,不啟用Named Pipes,即 命名管道 功能即可解決這個問題.
后經(jīng)查找相關(guān)資料得知,遠程連接超時可能由于Mysql默認開啟了DNS反向解析的緣故,每次連接時服務(wù)器都嘗試解析連接客戶端的主機名,導(dǎo)致時間比較長.
解決辦法是在服務(wù)器端的my.ini文件中,[mysqld]這個節(jié)下配置一個skip-name-resolve以關(guān)閉Mysql默認開啟的DNS反向解析就可以了.
再次通過設(shè)備和虛擬機或者Windows系統(tǒng)進行Telnet,可以發(fā)現(xiàn)連接超時的現(xiàn)象明顯不存在了.
MYSQL數(shù)據(jù)庫另外通過自己寫的C代碼進行連接的時候也存在同樣的問題,修改skip-name-resolve以后,實際上就可以發(fā)現(xiàn)該問題已經(jīng)不存在了：
MYSQL數(shù)據(jù)庫設(shè)備：
MYSQL數(shù)據(jù)庫[DPtech-Developer-Shell]/tcpclient_mips 10.101.0.1 3306
花費時間:10520
Recved 68 bytes
@
5.5.2-m2-community[Z44E>G)
虛擬機：
[root]tcp_demo# ./tcpclient 10.101.0.1 3306
花費時間:10521
Recved 68 bytes
@
5.5.2-m2-community7evE5wyx
MYSQL數(shù)據(jù)庫通過虛擬機Telnet連接另外一個ip 10.101.0.206時候發(fā)現(xiàn)速度也比較慢,消耗的時間基本上和設(shè)備中相當,可能是由于虛擬機和宿主主機之前不需要進行反向域名解析,或者說是應(yīng)為系統(tǒng)本身就知道虛擬機IP地址(NAT模式)對應(yīng)的主機名,所以不需要進行DNS反向解析,導(dǎo)致在虛擬機中出現(xiàn)了特殊情況.
最后得出結(jié)論,可能這個問題實際上和設(shè)備或者虛擬機,Linux系統(tǒng)、Windows系統(tǒng)沒有多大關(guān)系,主要由于服務(wù)器的反向DNS解析導(dǎo)致該問題.無法從客戶端途徑去辦理,也就是說我們設(shè)備無法處理這種情形.
歡迎參與《MYSQL教程Mysql DNS反向解析導(dǎo)致連接超時過程分析(skip-name-resolve)》討論，分享您的想法，維易PHP學院為您提供專業(yè)教程。
轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/13131.html
