There are several ways to identify the version of IoTDB that you are using:
> ./start-cli.sh -p 6667 -pw root -u root -h localhost _____ _________ ______ ______ |_ _| | _ _ ||_ _ `.|_ _ \ | | .--.|_/ | | \_| | | `. \ | |_) | | | / .'`\ \ | | | | | | | __'. _| |_| \__. | _| |_ _| |_.' /_| |__) | |_____|'.__.' |_____| |______.'|_______/ version x.x.x
<version>x.x.x</version>
String iotdbVersion = tsfileDatabaseMetadata.getDatabaseProductVersion();
IoTDB> show version show version +---------------+ |version | +---------------+ |x.x.x | +---------------+ Total line number = 1 It costs 0.241s
Suppose your root directory is:
$ pwd /workspace/iotdb $ ls -l server/ cli/ pom.xml Readme.md ...
Let $IOTDB_HOME = /workspace/iotdb/server/target/iotdb-server-{project.version}
Let $IOTDB_CLI_HOME = /workspace/iotdb/cli/target/iotdb-cli-{project.version}
By default settings, the logs are stored under IOTDB_HOME/logs. You can change log level and storage path by configuring logback.xml under IOTDB_HOME/conf.
By default settings, the data files (including tsfile, metadata, and WAL files) are stored under IOTDB_HOME/data/datanode.
Use IoTDB's Command Line Interface:
IoTDB> show timeseries
In the result, there is a statement shows Total timeseries number, this number is the timeseries number in IoTDB.
In the current version, IoTDB supports querying the number of time series. Use IoTDB's Command Line Interface:
IoTDB> count timeseries
If you are using Linux, you can use the following shell command:
> grep "0,root" $IOTDB_HOME/data/system/schema/mlog.txt | wc -l > 6
Yes. IoTDB has intense integration with Open Source Ecosystem. IoTDB supports Hadoop, Spark and Grafana visualization tool.
A data point is uniquely identified by a full time series path (e.g. root.vehicle.d0.s0) and timestamp. If you submit a new point with the same path and timestamp as an existing point, IoTDB updates the value of this point instead of inserting a new point.
Use SHOW TIMESERIES <timeseries path> SQL in IoTDB's Command Line Interface:
For example, if you want to know the type of all timeseries, the <timeseries path> should be root.**. The statement will be:
IoTDB> show timeseries root.**
If you want to query specific sensor, you can replace the <timeseries path> with the sensor name. For example:
IoTDB> show timeseries root.fit.d1.s1
Otherwise, you can also use wildcard in timeseries path:
IoTDB> show timeseries root.fit.d1.*
The default IoTDB's Cli time display format is readable (e.g. 1970-01-01T08:00:00.001), if you want to display time in timestamp type or other readable format, add parameter -disableISO8601 in start command:
> $IOTDB_CLI_HOME/sbin/start-cli.sh -h 127.0.0.1 -p 6667 -u root -pw root -disableISO8601
IndexOutOfBoundsException from org.apache.ratis.grpc.server.GrpcLogAppender?This is an internal error log from Ratis 2.4.1, our dependency, and no impact on data writes or reads is expected. It has been reported to the Ratis community and will be fixed in the future releases.
Report an error message:
301: There is not enough memory to execute current fragment instance, current remaining free memory is 86762854, estimated memory usage for current fragment instance is 270139392
Error analysis: The datanode_memory_proportion parameter controls the memory divided to the query, and the chunk_timeseriesmeta_free_memory_proportion parameter controls the memory available for query execution. By default the memory allocated to the query is 30% of the heap memory and the memory available for query execution is 20% of the query memory. The error report shows that the current remaining memory available for query execution is 86762854B = 82.74MB, and the query is estimated to use 270139392B = 257.6MB of execution memory.
Some possible improvement items:
It is an internal error introduced by Ratis 2.4.1 dependency, and we can safely ignore this exception as it will not affect normal operations. We will fix this message in the incoming releases.
cn_seed_config_node is configured correctly, which points to the alive ConfigNode. And if the ConfigNode is started for the first time, make sure that cn_seed_config_node points to itself.cn_seed_config_node ConfigNode.show cluster?cn_seed_config_node points to the correct address. If cn_seed_config_node points to itself, a new ConfigNode cluster is started.dn_seed_config_node points to the alive ConfigNode.remove-datanode.sh is correct, only rpcIp:rpcPort and dataNodeId are correct parameter.Removing.Removing, the regions in the removing DataNode will also in the status of Removing or Unknown, which are unavailable status. Besides, the removing DataNode will not receive new write requests from client. And users can use the command set system status to running to make the status of DataNode from Removing to Running; If users want to make the Regions from Removing to available status, command migrate region from datanodeId1 to datanodeId2 can take effect, this command can migrate the regions to other alive DataNodes. Besides, IoTDB will publish remove-datanode.sh -f command in the next version, which can remove DataNodes forced (The failed migrated regions will be discarded).remove-datanode.sh -f function in the next version.0.0.0.0, but the default RPC address of 1.0 is 127.0.0.1.stop-confignode.sh or kill PID of ConfigNode.start-confignode.sh to restart ConfigNode.stop-datanode.sh or kill PID of DataNode.start-datanode.sh` to restart DataNode.start-confignode.sh/start-datanode.sh successfully when delete the data directory of given ConfigNode/DataNode without killing the PID?remove-datanode.sh to fix it. Remove-datanode will migrate the data in the removing DataNode to other alive DataNodes.