其他分享
首页 > 其他分享> > tdengine jdbc连接报错: Unable to resolve FQDN; 其他情况报该错,也可用此方法处理。

tdengine jdbc连接报错: Unable to resolve FQDN; 其他情况报该错,也可用此方法处理。

作者:互联网

      最近因为项目原因,用到了涛思(taos)旗下的tdengine,踩到的一些坑,记录一下。

起因

      首先,服务端安装tdengine,按照官方文档即可,客户端使用时按照文档先安装并下载jar包。在 windows 环境开发时需要安装 TDengine 对应的 windows 客户端,Linux 服务器安装完 TDengine 之后默认已安装 client,也可以单独安装 Linux 客户端 连接远程 TDengine Server。详见官方文档:文档 | 涛思数据
      服务端可以理解成安装tdengine的服务器,客户端可以理解成你要操作的那台电脑。本人客户端是windows,所以先安装tdengine对应的客户端,然后再开发相关代码。
      按照官方文档编写完代码后,发现了部分问题。运行show create table test等语句时未报错,但是运行select * from test等语句时报错。报错原因为:Unable to resolve FQDN

查询官方文档

      然后就查官方文档,以下是和FQDN有关的且有帮助的官方文档:
      文档 | 涛思数据 | 数据模型和整体架构 链接:https://www.taosdata.com/cn/documentation/architecture
      文档 | 涛思数据 | 常见问题 链接:https://www.taosdata.com/cn/documentation/faq
      博客: 一篇文章说清楚TDengine的FQDN | 涛思数据 链接:https://www.taosdata.com/blog/2020/09/11/1824.html
      博客: TDengine 内嵌网络检测工具使用指南 | 涛思数据 链接:https://www.taosdata.com/blog/2020/09/08/1816.html
      

解决问题

      根据官方文档,域名配错了,hosts文件没修改的锅(修改DNS服务器也可以)。
      当看到这句话时:TDengine完全依赖FQDN来进行网络通讯,如果不了解FQDN,请看博文《一篇文章说清楚TDengine的FQDN》。(出自官方文档:https://www.taosdata.com/cn/documentation/architecture)我以为不能使用IP地址而必须使用域名才行。于是先修改hosts文件:127.1.2.3 node1,但是运行仍然报错:Unable to resolve FQDN
      根据官方文档,又去改客户端的配置文件,查看服务端的配置文件,都看到的是IP,没有域名。百度上资料又不多,很烦…
      继续看官方文档,无意间看到:确认客户端连接时指定了正确的服务器FQDN (Fully Qualified Domain Name(可在服务器上执行Linux命令hostname -f获得)),FQDN配置参考:一篇文章说清楚TDengine的FQDN。(出自官方文档:      文档 | 涛思数据 | 常见问题       博客: TDengine 内嵌网络检测工具使用指南 | 涛思数据

      也就是说,这个域名不能瞎写。即使服务端全写的IP,你也不能写IP。于是去服务端运行hostname -f,将得到的域名修改到客户端的hosts文件中,运行,成功~

问题分析

      继续查看官方文档。通过如下话语:
      集群的每个节点是由End Point来唯一标识的,End Point是由FQDN外加Port组成,比如 h1.taosdata.com:6030。这样当IP发生变化的时候,我们依然可以使用FQDN来动态找到节点,不需要更改集群的任何配置。
       物理节点(pnode): pnode是一独立运行、拥有自己的计算、存储和网络能力的计算机,可以是安装有OS的物理机、虚拟机或Docker容器。物理节点由其配置的 FQDN(Fully Qualified Domain Name)来标识。TDengine完全依赖FQDN来进行网络通讯,如果不了解FQDN,请看博文《一篇文章说清楚TDengine的FQDN》。
      数据节点(dnode): dnode 是 TDengine 服务器侧执行代码 taosd 在物理节点上的一个运行实例,一个工作的系统必须有至少一个数据节点。dnode包含零到多个逻辑的虚拟节点(VNODE),零或者至多一个逻辑的管理节点(mnode)。dnode在系统中的唯一标识由实例的End Point (EP )决定。EP是dnode所在物理节点的FQDN (Fully Qualified Domain Name)和系统所配置的网络端口号(Port)的组合。通过配置不同的端口,一个物理节点(一台物理机、虚拟机或容器)可以运行多个实例,或有多个数据节点。
      (反正都是上面那几篇文档,懒得写出自哪了。)
      因为刚接触,没有使用太长时间,也没有专门去研究架构和配置文件等内容,故而只能根据问题和解决办法和官方文档去推测。
      1. 有一个节点是存放元数据的(称其为管理节点),然后还有剩下的数据节点,是存放具体的数据的(称其为数据节点)。两个节点可以是一台机器。
      2. tdengine 2.0之后,完全依赖FQDN来进行网络通讯。也就是说,无论你配置文件怎么写,内部都是用FQDN。
      3. 如果没有配置,则默认使用节点所在服务器的hostname作为FQDN来使用。

      结论:使用IP可以连接到管理节点,因为管理节点存放元数据,所以show create table test等语句可以执行。
      节点间的通信只使用FQDN,所以:
      1. 如果是客户端连接管理节点,管理节点找数据节点要数据,而数据节点返回数据给管理节点,管理节点再把数据给客户端,那即使客户端不配置FQDN,也是可以收到数据的。但因为select * from test等语句无法执行,所以是错误的;同时,如果架构是这样,则管理节点回成为性能瓶颈。
      2. 如果是客户端连接管理节点,管理节点将数据节点的FQDN返回给客户端,然后客户端去连接数据节点要数据,数据节点将数据返回给客户端。这样就合理多了,且管理节点不会成为性能瓶颈。
      所以,我认为结论2合理。

      上面的结论都是我推论的,不代表肯定正确!!!
      
      

标签:resolve,TDengine,tdengine,FQDN,文档,报错,数据,节点,客户端
来源: https://blog.csdn.net/weixin_42845682/article/details/117549536