IoTDB 常见问题 Q&A 第五期

关于 IoTDB 的 Q & A
情人节之际,让 IoTDB Q&A 陪您一起共度解惑!我们将定期汇总我们将定期汇总社区讨论频繁的问题,并展开进行详细回答,通过积累常见问题“小百科”,方便大家使用 IoTDB。
Q1:导入数据时提示内存不足如何处理
问题现象
IoTDB 导入数据时提示内存不足,该如何处理?

解决方案
数据导入脚本会在触发内存不足的时候主动进行重试。当遇到此问题时,用户不用做任何操作,脚本也可以正确进行处理。如果想从根源减少此类提示,可以按照下述方案:
方案一:增大 DataNode 的堆内内存
方案二:减少当时的查询操作
方案三:调整内存分配比例,给查询先分配更多的内存。用户可以更改 iotdb-system.properties 中的 datanode_memory_proportion,为查询内存分配更高的比例份额

Q2:断电后无法启动 DataNode,日志提示 Meet error while starting up
问题
IoTDB 1.3.2 版本,断电后 IoTDB 的 DataNode 无法启动,日志如下:


问题原因
断电时文件系统产生某些意外错误,导致 data/datanode/system/pipe/reboot_times.txt 文件写入内容异常。
解决方案
出现该日志导致无法启动时,区分两种情况进行处置:
1. 如果系统中不存在 pipe 的使用,手动删除文件 data/datanode/system/pipe/reboot_times.txt 即可。
2. 如果系统中存在 pipe 的使用,请联系社区开发同学提供安全解决方案(可以参考 https://github.com/apache/iotdb/pull/14594 自行修改源码后启动,或升级最新社区版本 > v1.3.3)。
Q3:集群重启某节点失败
问题现象
IoTDB 1.3.3.6 版本部署的 3C3D 集群,在重启某个节点服务时失败,报错信息为节点冲突,日志部分截图如下:

问题原因
当前 IoTDB 会根据 data/confignode/system 路径下的 confignode-system.properties 文件及 data/datanode/system 路径下的 system.properties 文件去判断是否为重启加入集群。如果该文件被误删除,则可能导致重启时认为当前节点是要加入集群的新节点,而不是重新启动已存在的节点,进而产生如上报错。
解决方案
1. 可以按照日志提示信息,修改配置重新加入,成功后再移除掉失效的旧节点。
2. 如果实际情况不允许修改配置信息,则可以参考集群中其他节点的 confignode-system.properties 和 system.properties 文件,手动创建符合当前节点信息的 confignode-system.properties 和 system.properties,然后分别放到对应的 data/confignode/system 及 data/datanode/system 路径下,再启动即可成功。
Q4:集群节点 IP 改变,如何更新集群
问题
问题 1:如果 IoTDB 配置的时候用的 IP,没有用 hostname,后面 IP 修改了,历史数据需要重新导吗?
问题 2:如果现场运行 IoTDB 半年,电脑 IP 要改的话,半年的数据要导出来再导入么?
问题 3:有个关于 IoTDB 3C3D 集群,IP 地址更改的问题请教下。目前我们这儿 3C3D 集群,需要进行 IP 地址变更,之前配置文件里面,没有采用 hostname 模型,采用的是 IP 地址参数配置,请问服务器如果 IP 进行了变更,需要针对 IoTDB 集群进行如何调整,才能保证数据的完整性?
问题 4:有一个关于 IoTDB 1.3.1 的 TsFile load 问题需要请教下:
【问题场景】:原先采用 3C3D 配置的 IoTDB 集群,config 文件中没有采用 hostname 配置方式,采用的 IP 地址配置,但由于机器 IP 发生了变更,现需要进行 IoTDB 数据 TsFile 重新 load,以加载改 IP 之前录入 IoTDB 的数据。
【问题描述】:目前将 3 台服务器的老数据 data 文件夹,移动到了其他目录:/opt 目录下,目前需要加载 TsFile,是否直接全量加载 sequence 目录下的所有 TsFile 即可?还是说 snapshot 及其他目录的 TsFile,也需要进行 load?但是 snapshot 目录下 sequence 和 unsequence 目录下都有 TsFile,我该选哪个进行 load 才能全量保留之前的数据?
问题 5:请问下,3 节点的集群,将原先的 IP 地址参数改成了主机名字。现在往 IoTDB 中写数据时,session 还是通过 IP 来的,但是 IP 有的时候会去解析其他节点的主机名,发现解析不了而报错。请问这种情况该如何解决?
问题 6:刚开始电脑部署的 IoTDB 数据库以 127.0 IP 运行,现在想改为以 hostname 运行、因为不能改配置中的 IP,历史数据我可以不要,所以我重新下载了 1.3.0 版本,配置为 hostname 运行成功,但 CLI 连不上,什么原因呢?这样建立新的文件夹,重启新数据库做法可行吗?
方案
集群部署前的准备:推荐使用合适的 hostname,具体原因可参考《为什么推荐将 IoTDB 服务地址配置为 HostName 而非 IP?》。
集群部署后,IP 地址改变的处理
需要旧集群数据的情况:
搭建并配置新集群:新集群之间需要在每台主机的 /etc/hosts 文件中配置 IP 地址和对应主机名的关系,以确保它们能够相互识别(注意,hostname 必须唯一),之后可以启动新集群。
迁移老集群数据到新集群:可以通过 pipe 同步全量数据,直接将老集群的 data/ 目录(包括 sequence 和 unsequence)加载到新集群中。
不需要旧集群数据的情况:
停止旧集群。
删除旧集群的 data 目录和 logs 目录。
修改新集群及其所在主机的 host 配置。
启动新集群。
集群迁移后,客户端连接更新
在 CLI 连接时,需加上 -h hostname 参数。
对于使用 session 或 sessionPool 的客户端,建议也更新为对应的主机名(hosts)。
Q5:节点宕机后集群恢复
问题及现象
现象 1:IoTDB 集群一台电脑硬盘坏了,换了新硬盘迁移数据只能用 load 么?是不是直接新增节点就行了?
现象 2:这个错误是什么原因引起的?集群有个节点宕机,上线之后就报错:
现象 3:请教个问题,双副本集群中,一个节点宕机后,WAL 会持续增加,如果机器无法恢复,需要怎么解决?
现象 4:如果 3C3D 的模式下,设置了三个元数据副本,两个数据副本,其中一个节点有问题后会影响另外两个节点的工作么?如果移除那个有问题的节点后会存在数据丢失么?看官方文档说会把移除节点的数据自动同步到剩余两个节点中,又在文档中说不能少于元数据 3 副本的节点数运行,那三个节点的集群岂不是照样一个节点都不能挂?
现象 5:如果老节点挂掉了,是不是拿不到之前节点上的数据了?如果是单副本,那数据是取不到吗?
方法
单机版节点宕机:在其他主机上配置新节点,重新启动,并将旧节点的 /data 目录 load 进新节点。
集群内某个节点宕机之后:
节点能启动:手动启动该节点,启动后如果依然报下面的错,V1.1.0 及之前的版本先升级到最新版本,尝试调大 WAL 文件总大小配置 iot_consensus_throttle_threshold_in_byte 并重启该 DataNode 服务。
节点无法启动:在其他主机上配置一个新的节点,指向该集群,启动该节点加入集群。CLI 连接上该集群其他 DataNode,移除掉已经宕机的节点。
原因
无法移除 DataNode 的情况:当集群只有 3 个 DataNode 且每个有 3 副本时,无法移除某个 DataNode,系统不允许分片的副本数小于配置值。建议先增加一个 DataNode,达到 4 个节点后再移除出问题的节点,因为如果 DataNode 数量不足,系统不支持主动移除节点,这样可能导致副本数少于配置值。但如果是被动宕机,集群仍能正常工作。
拒绝写入的错误原因:如果某个节点长时间宕机,数据副本会一直无法同步,直到达到一定的阈值(默认 50G)后,保护机制会启动。重启后,由于待同步的 WAL 文件过多,通过增大 WAL 总文件大小配置,可以暂时避免阻塞节点间的数据同步。当前版本在节点长时间宕机的情况下,仍然需要通过恢复或移除节点的方式来解决 WAL 堆积问题。未来版本会优化这方面的设计,避免 WAL 堆积再次发生。
评论