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