程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> Mysql DNS反向解析導致連接超時過程分析(skip-name-resolve)

Mysql DNS反向解析導致連接超時過程分析(skip-name-resolve)

編輯:MySQL綜合教程

MySQL數據庫收到一個網絡連接後,首先拿到對方的IP地址,然後對這個IP地址進行反向DNS解析從而得到這個IP地址對應的主機名。用主機名在權限系統裡面進行權限判斷。反向DNS解析是耗費時間的,有可能讓用戶感覺起來很慢。甚至有的時候,反向解析出來的主機名並沒有指向這個IP地址,這時候就無法連接成功了。

可以在配置文件裡面禁止MySQL進行反向DNS解析,只需在my.cnf的[mysqld]段落中加入如下行即可:

skip-name-resolve (windows與linux下一樣的)

設備在連接mysql時候,等待服務器的banner信息需要4s左右,影響了Mysql服務的連接速度。
通過如下方式進行驗證:

1、Telnet端口驗證

通過設備和虛擬機(Linux系統)分別Telnet Mysql服務的端口,會出現一下現象:

設備(UAG/SCANNER): telnet後,等待Mysql的服務器端回應大概需要等10s左右。

[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服務器的返回

[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.   //這裡耗時很短

2、通過程序進行驗證

具體源代碼見附件:驗證程序源代碼
源代碼基本上是設置了Recv超時後,建立socket連接之後接受數據,收到後計時並輸出。

在設備上和虛擬機中的結果分別如下:
設備:

[DPtech-Developer-Shell]/tcpclient_mips 10.101.0.1 3306
花費時間:19553
Recved 68 bytes
@
5.5.2-m2-community%uD3q`n)

虛擬機:

[root]tcp_demo# ./tcpclient 10.101.0.1 3306
花費時間:10525
Recved 68 bytes
@
5.5.2-m2-communitd~k~Y";B

可以發現,設備上大約比Linux服務器多耗時9s,其中10秒鐘可能是recv本身超時的時間。

3、通過不同操作系統進行Telnet驗證

通過Windows系統和Linux虛擬機、設備,分別通過Telnet進行連接嘗試,通過抓包分析得知,只有設備的耗時比較長,其他的耗時都比較短。
抓包時發現設備中的socket建立之後,MYSQL服務器需要發送很多次的NBNS報文後,才會傳輸banner信息,而Linux虛擬機和Windows系統的主機在這個過程中都沒有出現這個問題。
查找了一些資料,關於MYSQL NBNS報文的問題:

Mysql論壇的提問:

http://forums.mysql.com/read.php?11,250982,250982#msg-250982

該問題的答復
http://forums.mysql.com/read.php?11,250982,254683#msg-254683

從答復中來看,貌似是某些版本的問題,臨時的解決方案是對Mysql服務器進行配置,不啟用Named Pipes,即 命名管道 功能即可解決這個問題。

後經查找相關資料得知,遠程連接超時可能由於Mysql默認開啟了DNS反向解析的緣故,每次連接時服務器都嘗試解析連接客戶端的主機名,導致時間比較長。

解決方法是在服務器端的my.ini文件中,[mysqld]這個節下配置一個skip-name-resolve以關閉Mysql默認開啟的DNS反向解析就可以了。

再次通過設備和虛擬機或者Windows系統進行Telnet,可以發現連接超時的現象明顯不存在了。

另外通過自己寫的C代碼進行連接的時候也存在同樣的問題,修改skip-name-resolve以後,實際上就可以發現該問題已經不存在了:

設備:

[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

通過虛擬機Telnet連接另外一個ip 10.101.0.206時候發現速度也比較慢,消耗的時間基本上和設備中相當,可能是由於虛擬機和宿主主機之前不需要進行反向域名解析,或者說是應為系統本身就知道虛擬機IP地址(NAT模式)對應的主機名,所以不需要進行DNS反向解析,導致在虛擬機中出現了特殊情況。
最後得出結論,可能這個問題實際上和設備或者虛擬機,Linux系統、Windows系統沒有多大關系,主要由於服務器的反向DNS解析導致該問題。無法從客戶端途徑去解決,也就是說我們設備無法處理這種情形。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved