作为一个数据库开发者，或者一个大型系统的开发者，日常就是不断观测，测试改动在某些场景中的表现是不是符合我们预期，如果符合，那就谢天谢地
读博时候，我没觉得项目开源后能有同学毕业继续参与，也没想到自己当了这个第一个吃螃蟹的人，这是一个生产关系的创新，国家提，这就是典型的升米恩，斗米仇。我们决定出来创业，一个很大的原因是，每当7、8、9月份，实验室同学们实习、找工作、毕业季，就是人力荒的时候，而且毕业生都是干了三年的项目骨干。
实验室今年的硕士毕业生陈荣钊，自从大四进组就负责 IoTDB 系统管理节点 ConfigNode 的开发，我们一起支持过无数项目，也是在原理、讲的存储引擎架构，我都会。朴素的、具象的、指标清晰的，大家容易认为是“工程问题”，酷炫的、抽象的，指标模糊的，大家容易认为是“科研问题”。
经历了几年的配合，在面对一个问题时的解决思路，我们基本能达成90%以上的一致性，因此我俩一般不需要一起开大会，十分钟就能快速同步一天的有效信息，因为知道对方关心哪些内容。在数据库的开发过程中，有大大小小的信息会在各个时间、各个地方产生，小到一个变量的命名，中到一段代码是否要进行复用还是再写一套，大到发现
比如一个餐饮店自己开发了一个下单软件，这个软件每天要服务多少人次的订单，是有一定规律的，对软件性能和功能的需求也比较明确
第二种是嵌入式场景，只支持 C/C++ 环境，内存几十兆，需要实时采集数据，存储上传。数据库是个综合的系统，单一的技术优势和技术劣势都
在低版本的 IoTDB 当中，Compaction 时出现上述异常，会将对应的 DataNode 设置为 ReadOnly 的状态，此时该节点会无法进行写入请求。还有两个 DataNode 节点是好的，连接好的 DataNode 节点写入是没有问题的，但是剩下的节点就不行了。更新至时序数据库 IoTDB 1.3.3 及以上版本。
1.3.0 版本数据库的 TTL 设置为两天，show databases details 看到设置也是正确的，怎么还是可以查到好几天前的数据？因为有很多不活跃的测点，所以专门设置了两天过期，有什么办法可以自动清理呢？设置方式是在配置文件统一设置的。
写入数据时首先写入 memtable，记录 wal，并没有直接落盘。在 CLI 中手动执行 flush 可以将当前 memtable 的所有数据持久化到磁盘上，将 TsFile
1.3.3 版本 IoTDB 执行查询操作失败，日志打印提示 Too many open files。如果条件允许（系统资源利用率不高，对其他模块无影响的情况下），可以适当再调大合并写入限速、合并任务并发数，加速合并。过多可以调优合并，顺序文件或者乱序文件过多可以修改配置。解决方案：观察顺乱序文件数目以及各个模块文件的大小，解决方案：降一点客户端并发。
安装包自带的脚本 daemon-confignode.sh 和 daemon-datanode.sh 配置看门狗后，使用“kill -9 ConfigNode 进程号 DataNode 进程号
数据导入脚本会在触发内存不足的时候主动进行重试。当遇到此问题时，用户不用做任何操作，脚本也可以正确进行处理。导入数据时提示内存不足，该如何处理？
断电时文件系统产生某些意外错误，导致 data/datanode/system/pipe/reboot_times.txt 文件写入内容异常。如果系统中不存在 p
如果实际情况不允许修改配置信息，则可以参考集群中其他节点的 confignode-system.properties 和system.properties 文件，手动创建符合当前节
【代码】IoTDB 节点宕机后集群恢复。
目前我们这儿 3C3D 集群，需要进行 IP 地址变更，之前配置文件里面，没有采用 hostname 模型，采用的是 IP 地址参数配置，请问服
重启成功后，可以先通过 CLI 窗口验证一下 SSL 是否配置成功。SSL（Secure Sockets Layer）是一种安全协议，用于在网络通信中提
包引用存在差异，导致插件中原本引用的 1.2 版本 TsFile 包下的 Tablet 类无法找到，进而使得 Kafka 插件无法正常发送数据，影输通道；
读取大量数据，经过一定分析后写入 MySQL 或 SQL Server 的场景下，寻求最适合的 ETL（Extract，Transform，Load）方案。若采用 Io
通过 Grafana 监控发现，发送端 DataNode 的 Heap Memory 中老年代存在部分内存无法随垃圾回收（GC）过程释放，随着运行时间的推移，
1.3.3 版本进行 Pipe 数据同步时，数据发送方出现内存不足报错，具体信息为：“failed to allocate because there’s too much me
3C3D 集群中，进行查询时报可用内存不足，即使是 show devices 这样简单的查询也会报内存不足。以后如果遇到集群性能发挥不佳的情况，可以排查一下集群间的网络延迟情况，这个对集群性能影响还是比较大的。采用上述解决方案后，查询可用内存不足的问题得到解决，同时查询效率得到明显提升。
1.3.2 版本升级到了 1.3.3（通过替换 lib 的方式）。替换后发现原有触发器，show triggers 显示 active，但实际并未生效。卸载安装后依旧无法监听路
当前版本中，删除序列时所有元数据引擎的缓存都需要强一致性失效，某一节点不能成功则全部失败。因此元数据删除
Continuous Query 执行阶段运行在 DataNode 中，但 Continuous Query 的调度和控制阶段（比如定时向 DataNode 发起查询）是
在版本 1.1.1 中，group by 遇到两列数据相加时，其中一列为 null，另一列属性不为 null，导致两者相加之后为 null，有类似 ifnull
通过 tools/import-data.sh 命令导入数据时，需要指定 -typeInfer 参数，用于指定类型推断规则，如：<srcTsDataType1=dstTs
时序数据库。
【代码】IoTDB GC 时间过长导致集群卡住。
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
