小T導(dǎo)讀：很多新用戶在配置TDengine Database的時候，偶爾會因?yàn)闆]有配置好FQDN，導(dǎo)致出現(xiàn)“unable to resolve FQDN”問題。所以大家會因?yàn)檫@個問題向TDengine的研發(fā)團(tuán)隊(duì)求助。本文會講解FQDN的相關(guān)設(shè)計(jì)和配置，希望能幫助用戶避免類似問題。

關(guān)于TDengine Database的FQDN機(jī)制，很多用戶都表示：為什么TDengine要使用它，直接用IP不好嗎？

其實(shí)是這樣，早在2.0之前的版本TDengine 確實(shí)是使用IP的。但是考慮到很多生產(chǎn)環(huán)境下IP都是會變動的，所以自2.0版本后，我們就引入了FQDN機(jī)制。

首先，為了避免混淆，我們要澄清兩個概念，避免混淆，一個是TDengine的“fqdn參數(shù)”，一個是作為網(wǎng)絡(luò)服務(wù)的FQDN概念本身。當(dāng)作為一個概念的時候，F(xiàn)QDN又和域名、hostname這些概念有關(guān)，因此我們需要仔細(xì)理解。

所以，為了讓大家理清這個邏輯，在文章中我們會用“fqdn參數(shù)”和“FQDN”來分別指代參數(shù)和FQDN概念本身。

FQDN的全稱是Fully Qualified Domain Name。與域名相對，我們暫且翻譯成全域名比較好理解一點(diǎn)。

FQDN分為兩部分組成：

1.Hostname：主機(jī)名，一般來說Linux當(dāng)中運(yùn)行hostname命令就可以獲取，例如TDengine1；

2.Domain：域名，如taosdata.com。

所以一個全域名可以簡單理解為一個帶著主機(jī)名的域名。

因此，上述情況下一個完整的FQDN就應(yīng)該是 tdengine1.taosdata.com。但是為了方便快速體驗(yàn)，TDengine在安裝后會直接默認(rèn)取本機(jī)的hostname——TDengine1作為fqdn參數(shù)的值。

概念和背景介紹完之后，接下來我們進(jìn)入配置階段：

首先我們要明確的一件事就是——只要你需要從客戶端遠(yuǎn)程連接TDengine，那么服務(wù)端的fqdn參數(shù)強(qiáng)烈建議要手動配置而不是默認(rèn)值。而且在配置的時候，不論是ip形式還是FQDN形式都是可以提供給客戶端用于連接的，配置方式如下：

在修改fqdn參數(shù)之后，我們要在/etc/hosts文件中（或DNS服務(wù)）添加上TD1和對外的ip地址。

最后，修改/var/lib/taos/dnode/dnodeEPs.json里面的fqdn信息，數(shù)據(jù)庫服務(wù)就可以正常啟動了。（如果初次安裝數(shù)據(jù)庫，服務(wù)仍未啟動，則不會生成這些文件，可以忽略本步驟）

了解了服務(wù)端配置的正確配置方法后，接下來，我們才要開始分析客戶端的連接問題。

其實(shí)，不論在服務(wù)端fqdn參數(shù)中指定的值是不是IP，客戶端都是可以直接用IP來與服務(wù)端建立連接的。

如下圖所示，分別是Linux和Windows客戶端的連接界面：

所以，這套機(jī)制的核心不在于taos -h的參數(shù)是IP還是fqdn參數(shù)值。而是在于從服務(wù)端取回的fqdn參數(shù)值能否被解析成正確的IP，它才是關(guān)乎于你能否順利操作數(shù)據(jù)的關(guān)鍵。

接下來，我要給大家舉兩個反例，也是大家經(jīng)常遇到的兩個場景。

已知，服務(wù)端的IP地址為192.168.56.161，fqdn參數(shù)設(shè)置為TD1。

出現(xiàn)場景1的原因是——在這個客戶端的hosts文件（或者DNS服務(wù)）中，沒有寫TD1。上圖中，客戶端用taos -h 192.168.56.161連接到TDengine服務(wù)端，取回TD1作為通訊地址。當(dāng)執(zhí)行查詢的時候，TDengine試圖把TD1解析成ip卻發(fā)現(xiàn)TD1并不在其中——這就是Unable to resolve FQDN。

場景2:

已知，服務(wù)端的IP地址為192.168.56.161，fqdn參數(shù)設(shè)置為TD1。

當(dāng)查詢數(shù)據(jù)的時候，TDengine試圖把TD1在hosts文件（或DNS服務(wù)）中解析成IP。但是由于IP地址寫錯了。因此客戶端解析出來的IP地址并不可用，從而無法建立連接——也就出現(xiàn)了“Unable to establish connection”的問題。

針對以上這兩個常見問題，我們只要把服務(wù)端的fqdn參數(shù)值和IP，正確地寫入到客戶端的hosts（或DNS服務(wù)）文件中就好了。

那么，前面提到過的“如果需要客戶端遠(yuǎn)程連接TDengine，我們就一定要手動修改服務(wù)端的fqdn參數(shù)值”又是為什么呢？

是這樣的：因?yàn)門Dengine會默認(rèn)讀取本機(jī)的hostname作為fqdn參數(shù)的值，所以很多新安裝的數(shù)據(jù)庫服務(wù)的fqdn參數(shù)都是“l(fā)ocalhost”，或是“ubuntu”之類的名字。這時候如果你的客戶端hostname恰好也是localhost或者ubuntu，解析后，客戶端就會直接連到127.0.0.1（自己）——unable to establish connection發(fā)生了。

這個問題是新用戶遇到頻率超高的典型問題，所以最好的辦法還是自己寫一個新的fqdn值。

上述只是針對單節(jié)點(diǎn)數(shù)據(jù)庫的連接情況，在集群中情況稍有不同，但原理始終一致。

如下圖所示：A, B, C三臺機(jī)器上分別部署TDengine形成集群。每個節(jié)點(diǎn)都是通過自身的hosts（DNS服務(wù)）文件解析FQDN后，尋址到IP后通過網(wǎng)絡(luò)層互相通訊。

比如：當(dāng)TD-A節(jié)點(diǎn)發(fā)送消息給TD-B的時候，需要在TD-A自身，找到TD-B對應(yīng)的IP。因此我們需要在節(jié)點(diǎn)A的hosts（DNS服務(wù)）中添加節(jié)點(diǎn)B。

同理，當(dāng)TD-B節(jié)點(diǎn)在主動給TD-A發(fā)送消息時，也需要在TD-B自身當(dāng)中，找到TD-A對應(yīng)的IP。因此我們需要在節(jié)點(diǎn)B的hosts（DNS服務(wù)）中添加節(jié)點(diǎn)A。

TD-C同上。

因此，如果節(jié)點(diǎn)之間互相通訊時出現(xiàn)Unable to resolved FQDN，一定是某一方的hosts文件（DNS服務(wù)）里，找不到對應(yīng)的FQDN。

接下來我們加入客戶端：

（這里我們要提一下TDengine的架構(gòu)，其實(shí)在每一個安裝包中都是自帶客戶端的，所以上面提到的情況中客戶端已經(jīng)在參與了，本段提及的客戶端特指客戶端與服務(wù)端分離的情況）

客戶端和集群之間的通訊，通常是我們出錯的重災(zāi)區(qū)。因?yàn)門Dengine點(diǎn)對點(diǎn)的設(shè)計(jì)，容易讓用戶忽略掉除連接目標(biāo)以外的集群服務(wù)器的網(wǎng)絡(luò)問題。

一個正常的客戶端遠(yuǎn)程連接集群的架構(gòu)圖應(yīng)該如下圖所示——TD-A，TD-B，TD-C都需要存在于客戶端的hosts（DNS服務(wù)）當(dāng)中。

在以上整個使用FQDN的鏈路當(dāng)中，有任何1個不通都會出問題，但是這類錯誤通常都具有隱蔽性：我們知道TDengine是一款分布式的大數(shù)據(jù)處理引擎，所以它的數(shù)據(jù)不只存在于一個節(jié)點(diǎn)上，也不是只有一份。這時候如果你的客戶端沒有完全添加所有的fqdn到hosts（DNS服務(wù)）中，就可能會出現(xiàn)下面這種現(xiàn)象：

前幾天你搭建了集群，show dnodes看到節(jié)點(diǎn)都是ready，隨便查詢了幾張表都OK，寫入幾個表也沒問題——測試過了，萬事大吉。

但是未來的某一天，你突然發(fā)現(xiàn)在寫入某張表的時候TDengine報錯了，但是寫入一些其他表就沒問題——這是怎么回事呢？難道是bug？

并不是那樣。

首先，集群中的數(shù)據(jù)庫一般都是多副本的，這意味著一個虛擬數(shù)據(jù)節(jié)點(diǎn)（vnode）有多個副本，以Master-slave形式存在。而TDengine的查詢操作可以在任意（Master或者Slave）節(jié)點(diǎn)進(jìn)行，但是寫入操作只能在 Master 節(jié)點(diǎn)上進(jìn)行。所以，如果當(dāng)你寫入的那個表的Master節(jié)點(diǎn)恰巧就在你無法通過fqdn連接到的節(jié)點(diǎn)上時，這個寫入操作就會報錯。

事實(shí)上，集群連接的報錯邏輯和單機(jī)版是類似的：如果客戶端服務(wù)器沒有在hosts（DNS服務(wù)）文件中配置正確的FQDN名字，就會報——unable to resolve FQDN。如果配置了FQDN名字但是ip配錯了，就會報——unable to establish connection或者database not ready。

所以，這部分問題一般都是配置疏漏導(dǎo)致，官方文檔原文如下：

“客戶端也需要配置，確保它可以正確解析每個節(jié)點(diǎn)的fqdn配置，不管是通過DNS服務(wù)，還是 hosts 文件?！?/p>

因此，最簡單的確認(rèn)配置方法就是去查看所有節(jié)點(diǎn)的hosts（DNS服務(wù)）內(nèi)容，看看他們關(guān)于集群節(jié)點(diǎn)的配置信息是否一模一樣就可以了。

能看到這里并仔細(xì)思考過的讀者們，我相信你一定已經(jīng)掃清了關(guān)于FQDN的障礙了。而且，因?yàn)橐恍┨囟▓鼍跋鲁霈F(xiàn)的FQDN問題會結(jié)合著TDengine的典型的產(chǎn)品特性，所以借助這個問題你可以更加深入地理解TDengine的體系架構(gòu)，為自己未來的使用做好更多的鋪墊。

最后偷偷告訴大家，未來TDengine會在錯誤提示方面做出更多優(yōu)化——以FQDN為例，將會告訴大家是從哪個節(jié)點(diǎn)到哪個節(jié)點(diǎn) “unable to resolve FQDN”，這樣我們在遇到相關(guān)問題后，處理起來就會更加得心應(yīng)手了。