共计 3522 个字符，预计需要花费 9 分钟才能阅读完成。
小 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”，这样咱们在遇到相干问题后，解决起来就会更加得心应手了。
