小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"，这样咱们在遇到相干问题后，解决起来就会更加得心应手了。