Skip to content

README.md

Latest commit

 

History

History
493 lines (422 loc) · 24 KB

README.md

File metadata and controls

493 lines (422 loc) · 24 KB
Raw

Release version

Version IoTDB Binaries IoTDB Sources release notes
2.0.8 All-in-one SHA512 ASC Sources SHA512 ASC release notes
AINode linux-aarch64 SHA512 ASC
1.3.7 All-in-one SHA512 ASC Sources SHA512 ASC release notes
0.13.4 All-in-one SHA512 ASC Sources SHA512 ASC release notes
Grafana-connector SHA512 ASC
Grafana-plugin SHA512 ASC

Legacy version are available here: https://archive.apache.org/dist/iotdb/

Configurations

  • Recommended OS parameters

    • Set the somaxconn as 65535 to avoid "connection reset" error when the system is under high load.

      # Linux
> sudo sysctl -w net.core.somaxconn=65535

# FreeBSD or Darwin
> sudo sysctl -w kern.ipc.somaxconn=65535

How to Upgrade

General Rules

  • Minor version upgrades before v1.0.x (e.g., upgrading from v0.12.4 to v0.12.5)

    • Minor versions under the same major version are generally compatible with each other.
    • Simply download the new minor version and modify its configuration file to match the settings of the original version.
    • Stop the old version process and start the new version.

  • Minor version upgrades for v1.0.x and later

    • It is recommended to stop the service before performing the upgrade operation.
    • Download and extract the target version.
    • Usually, you need to replace the lib and sbin folders.
    • If the target version introduces new configuration items or script changes, it is recommended to synchronously check and merge the contents of directories such as conf and tools as needed.
    • Start the new version instance and verify the service status.

  • Cross-version upgrades

    • Before upgrading across major versions or important minor versions, it is recommended to back up data and configurations first for rollback purposes.
    • Stop writing before the upgrade, and perform flush, shut down the old version instance and other operations as required by the target version.
    • Do not upgrade directly across multiple major versions; it is recommended to upgrade step by step according to versions.
    • After the upgrade, check key configurations, data directories and service status to confirm that the version switch is successful.

Version Upgrade Instructions

  • How to upgrade from v2.0.4 and above to v2.0.8?

    • Stop writing and shut down the old version instance.
    • Download and extract v2.0.8.
    • Replace the lib and sbin folders.
    • Start the v2.0.8 instance and verify the service status.

  • How to upgrade from versions below v2.0.4 to v2.0.8?

    • Stop writing and shut down the old version instance.
    • It is recommended to back up data, configurations and script files in advance for rollback purposes.
    • Download and extract v2.0.8.
    • Replace the new version's conf, lib, sbin and tools folders.
    • conf/iotdb-system.properties can use the old version configuration, and other configurations are recommended to be merged item by item according to the new version content.
    • Start the v2.0.8 instance and verify the service status.

  • How to upgrade from v1.3.x to v2.0.8?

    • Back up data before upgrading.
    • Replace the lib and sbin folders.
    • Copy iotdb-common.sh from the v2.0.8 conf directory to the original v1.3.x conf directory.
    • Before starting v2.0.8, it is recommended to check whether the configuration and data directories meet the requirements of the target 2.0.x version.
    • Start the v2.0.8 instance and verify the service status.

  • How to upgrade from lower versions to v2.0.x?

    • Do not upgrade directly across versions; it is recommended to upgrade step by step according to versions.
    • For example, when upgrading from v1.1.x to v2.0.x, it is recommended to follow the order v1.1.x -> v1.2.x -> v1.3.x -> v2.0.x.
    • It is recommended to back up data and configurations before each upgrade for rollback purposes.

  • How to upgrade from v1.0.0 to v1.x.0?

    • Stop writing and shut down the old version instance.
    • Download the new version files.
    • Replace all the lib and sbin folders.
    • Restart the service.

  • How to upgrade from v0.13.x to v1.0.x?

    • The file directory structure of version 0.13 is different from that of version 1.0. You cannot directly copy the data directory from version 0.13 to a version 1.0 cluster for use. If you need to import data from 0.13 to 1.0, you can use the LOAD function.
    • The default RPC address for version 0.13 is 0.0.0.0, and the default RPC address for version 1.0 is 127.0.0.1.

  • How to upgrade from v0.12.x to v0.13.x?

    • The data file formats of 0.12 and 0.13 are compatible, but formats such as write-ahead logs are not compatible, so an upgrade is required.
    • Execute the SET SYSTEM TO READONLY command in the 0.12 CLI and stop writing new data.
    • Execute the flush command in the CLI to ensure all TsFile files are closed.
    • We recommend backing up the entire data directory in advance for rollback purposes.
    • Download the latest 0.13 version, extract it and modify the configuration file, especially configuration parameters that cannot be modified after the first startup such as timestamp precision, and point all data directories to the backed up or original data directories used by v0.12.
    • Stop the v0.12 instance and start the v0.13 instance.
    • After performing the above steps, please confirm that iotdb_version in the data/system/schema/system.properties file is 0.13.x. If not, please manually modify it to 0.13.x.
    • Note: The configuration file of 0.13 has been significantly modified, so do not directly use the 0.12 configuration file for 0.13.
    • 0.13 has made changes to SQL syntax. Identifiers not enclosed in backticks can only contain the following characters, otherwise they need to be enclosed in backticks.
      • [0-9 a-z A-Z _ : @ # $ { }] (letters, numbers, some special characters)
      • ['\u2E80'..'\u9FFF'] (Unicode Chinese characters)
    • In 0.13, if a path node name in the SELECT clause is a real number, it needs to be enclosed in backticks to distinguish it from constants in expressions. For example, in the statement 'select 123 + `123` from root.sg', the first 123 represents a constant, and the latter `123` will be spliced with root.sg to represent the path root.sg.`123`.

  • How to upgrade from v0.11.x or v0.10.x to v0.12.x?

    • The process of upgrading from 0.11 or 0.10 to 0.12 is similar to upgrading from v0.9 to v0.10, and the upgrade tool will automatically upgrade the data files.
    • Stop writing new data to the old version.
    • Call flush using the CLI to ensure all TsFile files are closed.
    • We recommend backing up data files, as well as write-ahead logs and mlog files in advance for rollback purposes.
    • Download the latest version, extract it and modify the configuration file. Point all data directories to the backed up or original data directories used by v0.11 or v0.10, and synchronize necessary configuration changes from the old version to 0.12.
    • Stop the old version IoTDB instance and start the v0.12 instance. IoTDB will automatically upgrade the data file format in the background. Data can be queried and written during the upgrade process.
    • The upgrade is successful when the log shows All files upgraded successfully!.
    • Note 1: The configuration file of 0.12 has been significantly modified, so do not directly use the original configuration file for 0.12.
    • Note 2: Since 0.12 does not support upgrading from 0.9 or lower versions, please upgrade to version 0.10 first if you need to upgrade.
    • Note 3: It is best not to perform delete operations before the file upgrade is completed. If you delete data in a database and there are files to be upgraded in that database, the deletion will fail.

  • How to upgrade from v0.10.x to v0.11.x?

    • The data file formats of 0.10 and 0.11 are compatible, but formats such as write-ahead logs are not compatible, so an upgrade is required.
    • Stop writing new data to 0.10.
    • Call flush using the CLI to ensure all TsFile files are closed.
    • We recommend backing up write-ahead logs and mlog files in advance for rollback purposes.
    • Download the latest version, extract it and modify the configuration file. Point all data directories to the backed up or original data directories used by v0.10.
    • Stop the v0.10 instance and start the v0.11 instance. IoTDB will automatically upgrade incompatible file formats.
    • Note: The configuration file of 0.11 has been significantly modified, so do not directly use the 0.10 configuration file for 0.11.

  • How to upgrade from v0.9.x to v0.10.x?

    • Stop writing new data to the old version.
    • Call flush using the CLI to ensure all TsFile files are closed.
    • We recommend backing up data files, as well as write-ahead logs and mlog files in advance for rollback purposes.
    • Download the latest version, extract it and modify the configuration file. Point all data directories to the backed up or original data directories used by v0.9.
    • Stop the v0.9 instance and start the v0.10 instance. IoTDB will automatically upgrade the data file format.

  • How to upgrade from v0.8.x to v0.9.x?

    • We recommend backing up data files, as well as write-ahead logs and mlog files in advance for rollback purposes.
    • Download the latest version, extract it and modify the configuration file. Point all data directories to the backed up or original data directories used by v0.8.
    • Stop the v0.8 instance and start the v0.9.x instance. IoTDB will automatically upgrade the data file format.

All releases

Find all releases in the Archive repository.

Verifying Hashes and Signatures

Along with our releases, we also provide sha512 hashes in *.sha512 files and cryptographic signatures in *.asc files. The Apache Software Foundation has an extensive tutorial to verify hashes and signatureswhich you can follow by using any of these release-signing KEYS.

About Version 1.0

After we release version 1.0, how to upgrade from v0.13.x to v1.0.x?

  • Version 1.0 has changed the SQL syntax conventions (please refer to the syntax conventions section of the user manual).
  • In order to ensure the stability of UDF-related APIs, in version 1.0, UDF-related APIs are seperated into an independent module and no longer depend on the tsfile package. The implemented UDFs need to rewrite the code, replace TsDataType with Type, and replace org .apache.iotdb.tsfile.utils.Binary with org.apache.iotdb.udf.api.type.Binary, then redo the packaging and loading process.

Detailed description of Syntax Conventions in version 1.0 that are different from older versions

In previous versions of syntax conventions, we introduced some ambiguity to maintain compatibility. To avoid ambiguity, we have designed new syntax conventions, and this chapter will explain the issues with the old syntax conventions and why we made the change.

Issues related to identifier

In version 0.13 and earlier, identifiers (including path node names) that are not quoted with backquotes are allowed to be pure numbers(Pure numeric path node names need to be enclosed in backquotes in the SELECT clause), and are allowed to contain some special characters. In version 1.0, identifiers that are not quoted with backquotes are not allowed to be pure numbers and only allowed to contain letters, Chinese characters, and underscores.

Issues related to node name

In previous versions of syntax conventions, when do you need to add quotation marks to the node name, and the rules for using single and double quotation marks or backquotes are complicated. We have unified usage of quotation marks in the new syntax conventions. For details, please refer to the relevant chapters of this document.

When to use single and double quotes and backquotes

In previous versions of syntax conventions, path node names were defined as identifiers, but when the path separator . was required in the path node name, single or double quotes were required. This goes against the rule that identifiers are quoted using backquotes.

# In the previous syntax convention, if you need to create a time series root.sg.`www.baidu.com`, you need to use the following statement:
create root.sg.'www.baidu.com' with datatype=BOOLEAN, encoding=PLAIN

# The time series created by this statement is actually root.sg.'www.baidu.com', that is, the quotation marks are stored together. The three nodes of the time series are {"root","sg","'www.baidu.com'"}.

# In the query statement, if you want to query the data of the time series, the query statement is as follows:
select 'www.baidu.com' from root.sg;

In the 1.0 syntax conventions, special node names are uniformly quoted using backquotes:

# In the new syntax convention, if you need to create a time series root.sg.`www.baidu.com`, the syntax is as follows:
create root.sg.`www.baidu.com` with 'datatype' = 'BOOLEAN', 'encoding' = 'PLAIN'

#To query the time series, you can use the following statement:
select `www.baidu.com` from root.sg;
The issues of using quotation marks inside node names

In previous versions of syntax conventions, when single quotes ' and double quotes " are used in path node names, they need to be escaped with a backslash , and the backslashes will be stored as part of the path node name. Other identifiers do not have this restriction, causing inconsistency.

# Create time series root.sg.\"a
create timeseries root.sg.`\"a` with datatype=TEXT,encoding=PLAIN;

# Query time series root.sg.\"a
select `\"a` from root.sg;
+-----------------------------+-----------+
|                         Time|root.sg.\"a|
+-----------------------------+-----------+
|1970-01-01T08:00:00.004+08:00|       test|
+-----------------------------+-----------+

In the 1.0 syntax convention, special path node names are uniformly referenced with backquotes. When single and double quotes are used in path node names, there is no need to add backslashes to escape, and backquotes need to be double-written. For details, please refer to the relevant chapters of the new syntax conventions.

Issues related to session API

Session API syntax restrictions

In version 0.13, the restrictions on using path nodes in non-SQL interfaces are as follows:

  • The node names in path or path prefix as parameter:
    • The node names which should be escaped by backticks (`) in the SQL statement, and escaping is not required here.
    • The node names enclosed in single or double quotes still need to be enclosed in single or double quotes and must be escaped for JAVA strings.
    • For the checkTimeseriesExists interface, since the IoTDB-SQL interface is called internally, the time-series pathname must be consistent with the SQL syntax conventions and be escaped for JAVA strings.

In version 1.0, restrictions on using path nodes in non-SQL interfaces were enhanced:

  • The node names in path or path prefix as parameter: The node names which should be escaped by backticks (`) in the SQL statement, escaping is required here.
  • Code example for syntax convention could be found at: example/session/src/main/java/org/apache/iotdb/SyntaxConventionRelatedExample.java
Inconsistent handling of string escaping between SQL and Session interfaces

In previous releases, there was an inconsistency between the SQL and Session interfaces when using strings. For example, when using SQL to insert Text type data, the string will be unescaped, but not when using the Session interface, which is inconsistent. In the new syntax convention, we do not unescape the strings. What you store is what will be obtained when querying (for the rules of using single and double quotation marks inside strings, please refer to this document for string literal chapter).

The following are examples of inconsistencies in the old syntax conventions:

Use Session's insertRecord method to insert data into the time series root.sg.a

// session insert
String deviceId = "root.sg";
List<String> measurements = new ArrayList<>();
measurements.add("a");
String[] values = new String[]{"\\\\", "\\t", "\\\"", "\\u96d5"};
for(int i = 0; i <= values.length; i++){
  List<String> valueList = new ArrayList<>();
  valueList.add(values[i]);
  session.insertRecord(deviceId, i + 1, measurements, valueList);
  }

Query the data of root.sg.a, you can see that there is no unescaping:

// query result
+-----------------------------+---------+
|                         Time|root.sg.a|
+-----------------------------+---------+
|1970-01-01T08:00:00.001+08:00|       \\|
|1970-01-01T08:00:00.002+08:00|       \t|
|1970-01-01T08:00:00.003+08:00|       \"|
|1970-01-01T08:00:00.004+08:00|   \u96d5|
+-----------------------------+---------+

Instead use SQL to insert data into root.sg.a:

# SQL insert
insert into root.sg(time, a) values(1, "\\")
insert into root.sg(time, a) values(2, "\t")
insert into root.sg(time, a) values(3, "\"")
insert into root.sg(time, a) values(4, "\u96d5")

Query the data of root.sg.a, you can see that the string is unescaped:

// query result
+-----------------------------+---------+
|                         Time|root.sg.a|
+-----------------------------+---------+
|1970-01-01T08:00:00.001+08:00|        \|
|1970-01-01T08:00:00.002+08:00|         |
|1970-01-01T08:00:00.003+08:00|        "|
|1970-01-01T08:00:00.004+08:00|       雕|
+-----------------------------+---------+