IoTDB 常见问题 Q&A 第二期

关于 IoTDB 的 Q&A

IoTDB Q&A 第二期来啦~我们将定期汇总社区讨论频繁的问题，并展开进行详细回答，通过积累常见问题“小百科”，方便大家使用 IoTDB。

Q1：集群扩容方法

问题

问题1：当 IoTDB 集群的存储占用达到多少时，建议增加节点？是等到存储完全满，还是达到一半时就进行扩容？如果集群存储已满，是否需要手动进行数据清理，比如设置 TTL，还是可以直接忽略，只增加节点即可？

问题2：目前使用三台服务器构建的集群配置了元数据 3 副本和数据 2 副本。现在想要将一年前的数据迁移到其他服务器上以释放空间，这个操作应该如何执行？

方案

（1）数据清理与扩容建议

• 自动数据清理：可以通过配置 TTL 自动清理过期数据，实现存储空间的自动回收。

• 扩容时机：建议根据集群存储资源的使用趋势和业务数据增长预期来决定扩容时机。一般而言，当存储利用率接近高水位线（例如 70%-80%）时，应考虑扩容以确保服务稳定性，而不是等到存储完全占满。

• 存储满时处理：若集群存储空间已满，建议优先通过设置 TTL 或其他方式清理无用数据。在此基础上，可以根据需求增加集群节点以提升存储能力。

（2）存储扩展方法

• 扩展磁盘：在当前集群负载正常的情况下，可以通过增加磁盘容量来扩展存储资源。IoTDB 支持多盘目录配置，可以灵活扩展存储能力。

（3）历史数据迁移操作

• 数据迁移步骤：对于需要迁移的历史数据，可以利用 IoTDB 的数据同步功能，将一年前的数据迁移至其他集群或服务器进行备份。

• 释放存储空间：迁移完成后，在当前集群中通过 TTL 配置清理已迁移的历史数据，从而释放存储空间。

• 操作注意事项：在进行数据迁移之前，确保目标服务器或集群具备足够的存储资源，并对迁移的关键步骤进行备份和测试，以确保数据安全和完整性。

Q2：GC 时间过长导致集群卡住

问题

1. 我们的业务系统在 IoTDB 执行 GC 时遭遇了查询和写入操作的短暂卡顿。此外，IoTDB 在运行一段时间后，老年代内存占用过高，即使在停止大量写入操作后仅进行查询，内存回收仍然不力。大约 4 至 5 天后，系统会记录此日志，并在此期间变得卡顿。虽然可以通过定时重启来缓解，但我们想寻求避免重启的解决方案。

系统环境：

• Java 版本：openjdk version "1.8.0_222-ea"；

• 测点数量：352130；

• DataNode MEMORY_SIZE：42G；

• 部署方式：单机部署

2. 我们观察到 IoTDB 的 GC 时间过长，是否需要增加内存？当前使用的是 JDK 11 版本。