如何徹底搞懂TDengine的fqdn概念？這一篇文章就夠了

小T導讀：很多新用戶在配置TDengine的時候，偶爾會因為沒有配置好FQDN，導致出現“unable to resolve FQDN”問題，所以大家會因為這個問題向TDengine的研發團隊求助，本文會講解FQDN的相關設計和配置，希望能幫助用戶避免類似問題，

關于TDengine的FQDN機制，很多用戶都表示：為什么TDengine要使用它，直接用IP不好嗎？

其實是這樣，早在2.0之前的版本TDengine 確實是使用IP的，但是考慮到很多生產環境下IP都是會變動的，所以自2.0版本后，我們就引入了FQDN機制，

首先，為了避免混淆，我們要澄清兩個概念，避免混淆，一個是TDengine的“fqdn引數”，一個是作為網路服務的FQDN概念本身，當作為一個概念的時候，FQDN又和域名、hostname這些概念有關，因此我們需要仔細理解，

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

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

FQDN分為兩部分組成：

1.Hostname：主機名，一般來說Linux當中運行hostname命令就可以獲取，例如TDengine1；

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

所以一個全域名可以簡單理解為一個帶著主機名的域名，

因此，上述情況下一個完整的FQDN就應該是TDengine1.taosdata.com，但是為了方便快速體驗，TDengine在安裝后會直接默認取本機的hostname——TDengine1作為fqdn引數的值，

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

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

在修改fqdn引數之后，我們要在/etc/hosts檔案中（或DNS服務）添加上TD1和對外的ip地址，

最后，修改/var/lib/taos/dnode/dnodeEPs.json里面的fqdn資訊，資料庫服務就可以正常啟動了，（如果初次安裝資料庫，服務仍未啟動，則不會生成這些檔案，可以忽略本步驟）

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

其實，不論在服務端fqdn引數中指定的值是不是IP，客戶端都是可以直接用IP來與服務端建立連接的，

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

所以，這套機制的核心不在于taos -h的引數是IP還是fqdn引數值，而是在于從服務端取回的fqdn引數值能否被決議成正確的IP，它才是關乎于你能否順利操作資料的關鍵，

接下來，我要給大家舉兩個反例，也是大家經常遇到的兩個場景，

已知，服務端的IP地址為192.168.56.161，fqdn引數設定為TD1，

出現場景1的原因是——在這個客戶端的hosts檔案（或者DNS服務）中，沒有寫TD1，上圖中，客戶端用taos -h 192.168.56.161連接到TDengine服務端，取回TD1作為通訊地址，當執行查詢的時候，TDengine試圖把TD1決議成ip卻發現TD1并不在其中——這就是Unable to resolve FQDN，

場景2:

已知，服務端的IP地址為192.168.56.161，fqdn引數設定為TD1，

當查詢資料的時候，TDengine試圖把TD1在hosts檔案（或DNS服務）中決議成IP，但是由于IP地址寫錯了，因此客戶端決議出來的IP地址并不可用，從而無法建立連接——也就出現了“Unable to establish connection”的問題，

針對以上這兩個常見問題，我們只要把服務端的fqdn引數值和IP，正確地寫入到客戶端的hosts（或DNS服務）檔案中就好了，

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

是這樣的：因為TDengine會默認讀取本機的hostname作為fqdn引數的值，所以很多新安裝的資料庫服務的fqdn引數都是“localhost”，或是“ubuntu”之類的名字，這時候如果你的客戶端hostname恰好也是localhost或者ubuntu，決議后，客戶端就會直接連到127.0.0.1（自己）——unable to establish connection發生了，

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

上述只是針對單節點資料庫的連接情況，在集群中情況稍有不同，但原理始終一致，

如下圖所示：A, B, C三臺機器上分別部署TDengine形成集群，每個節點都是通過自身的hosts（DNS服務）檔案決議FQDN后，尋址到IP后通過網路層互相通訊，

比如：當TD-A節點發送訊息給TD-B的時候，需要在TD-A自身，找到TD-B對應的IP，因此我們需要在節點A的hosts（DNS服務）中添加節點B，

同理，當TD-B節點在主動給TD-A發送訊息時，也需要在TD-B自身當中，找到TD-A對應的IP，因此我們需要在節點B的hosts（DNS服務）中添加節點A，

TD-C同上，

因此，如果節點之間互相通訊時出現Unable to resolved FQDN，一定是某一方的hosts檔案（DNS服務）里，找不到對應的FQDN，

接下來我們加入客戶端：

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

客戶端和集群之間的通訊，通常是我們出錯的重災區，因為TDengine點對點的設計，容易讓用戶忽略掉除連接目標以外的集群服務器的網路問題，

一個正常的客戶端遠程連接集群的架構圖應該如下圖所示——TD-A，TD-B，TD-C都需要存在于客戶端的hosts（DNS服務）當中，

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

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

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

并不是那樣，

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

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

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

“客戶端也需要配置，確保它可以正確決議每個節點的fqdn配置，不管是通過DNS服務，還是 hosts 檔案，”

因此，最簡單的確認配置方法就是去查看所有節點的hosts（DNS服務）內容，看看他們關于集群節點的配置資訊是否一模一樣就可以了，

能看到這里并仔細思考過的讀者們，我相信你一定已經掃清了關于FQDN的障礙了，而且，因為一些特定場景下出現的FQDN問題會結合著TDengine的典型的產品特性，所以借助這個問題你可以更加深入地理解TDengine的體系架構，為自己未來的使用做好更多的鋪墊，

最后偷偷告訴大家，未來TDengine會在錯誤提示方面做出更多優化——以FQDN為例，將會告訴大家是從哪個節點到哪個節點 "unable to resolve FQDN"，這樣我們在遇到相關問題后，處理起來就會更加得心應手了，