如何彻底搞懂 TDengine 中的 FQDN 概念？

导读：

FQDN 是 TDengine 中网络连接中的一个非常重要的概念，必须要理解透。

很多新用户在配置 TDengine 集群时候，经常会因为没有配置好 FQDN，导致出现 “unable to resolve FQDN” 问题。本文会详细讲解 FQDN的 相关设计、使用和如何配置，帮助更多使用者避免类似问题。

什么是 FQDN ，为什么要使用它，直接用 IP 不好吗？

其实是这样，早在 2.0 之前版本 TDengine 确实是使用 IP 的，但后来在实际使用过程中发现很多生产环境中 IP 会经常由于各种原因要改变，IP 一变动，给 TDengine 集群连接就造成很大的问题，所以自 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/dnode.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 的体系架构，为自己未来的使用做好更多的铺垫。