Mysql DNS反向解析招致銜接超時進程剖析(skip-name-resolve)

Mysql DNS反向解析招致銜接超時進程剖析(skip-name-resolve)。本站提示廣大學習愛好者：（Mysql DNS反向解析招致銜接超時進程剖析(skip-name-resolve)）文章只能為提供參考，不一定能成為您想要的結果。以下是Mysql DNS反向解析招致銜接超時進程剖析(skip-name-resolve)正文

---

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服裝論壇t.vhao.net的發問：

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解析招致該成績。沒法從客戶端門路去處理，也就是說我們裝備沒法處置這類情況。