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