首页
>
资源
>

TimechoDB V2.0.11.1发布：基于国密算法与双向证书校验，构建端到端可信传输通道

2026-08-28

TimechoDB V2.0.11.1 版本正式发布！

TimechoDB 由 IoTDB 原厂团队开发，为通过安全可靠测评且唯一明确为时序数据库的产品。

TimechoDB V2.0.11.1 聚焦数据可靠性、安全合规、高可用，修复了监控失真、共识层稳定性及 4 项关键 CVE 漏洞，新增审计埋点、国密通信、配置热加载；同时在 SQL 引擎、Pipe 同步能力显著增强，保障关键业务场景下大规模集群的稳定运行与端边云数据流转。

更多关于 V2.0.11.1 版本信息，欢迎点击文末阅读原文，联系我们获得企业版安装包！

主要更新

  • 数据可靠性：修复多盘存储及 Region 迁移场景下监控指标（CompressionRatio、TsFileSize）出现负值/NaN 的问题，确保运维数据准确可信，保障数据自愈能力。

  • 运维管控：新增 CANCEL ALL MIGRATIONS 全局指令，支持集群迁移任务一键中止；实现集群运行时配置热加载，无需重启即可生效。

  • 安全合规：补齐密钥管理、鉴权失败、Leader 选举等全链路审计日志埋点；修复 4 个关键 CVE 漏洞（含 Pipe 未鉴权、JDBC 内存耗尽等），满足等保要求。

  • 通信加密：新增国密通信加密与客户端 SSL 双向认证能力，修复 SSL 场景下报错信息不明确及空指针问题，强化传输层安全。

  • 高可用：修复 JDBC 客户端在节点重启后的重连失效问题；解决 Ratis 选主异常及 IoTConsensus 队列计算错误，提升集群稳定性与滚动升级体验。

  • Pipe 稳定性：优化 Pipe 内存计算与快照清理逻辑，解决日志刷屏及磁盘残留问题，保障数据同步链路可靠。

  • SQL 能力增强：支持逻辑视图、EXPLAIN ANALYZE 输出 JSON、查询仅含 SELECT 子句及后值填充（Prev Fill）功能；新增 GROUP BY/ORDER BY 使用别名支持。

  • 查询引擎优化：支持 show timeseries 排序，修复 cast 类型转换、date_bin_gap_fill 嵌套查询异常及树表模型数值对比不一致问题。

  • 资源与生态：修复SSH 连接不释放及 Schema Cache 不一致问题；JDK 升级至 17，新增 Node.js 客户端支持，并更新第三方依赖。

本版本详细发布内容见天谋科技官网：https://timecho.com/docs/zh/UserGuide/latest/IoTDB-Introduction/Release-history_timecho.html

功能详解：通讯加密

功能介绍

TimechoDB 支持加密客户端与服务端、以及集群节点之间的通信。客户端可通过 Java Session、SessionPool、JDBC、CLI、Python 或 Go 建立加密连接，Pipe 支持加密同步。Client RPC 支持标准 TLS 的单向认证和双向 SSL 认证（mTLS）；满足 Kona JDK、SM2 双证书和客户端兼容性要求时，也可配置 TLCP 1.1。

本页介绍的功能自 V2.0.11.1 起提供，默认关闭。启用后，客户端和集群节点必须使用与服务端兼容的协议，并信任服务端或节点证书，否则无法建立连接。

1. 功能说明

标准 TLS 可使用兼容的 RSA 或 ECDSA 证书；TLCP 1.1 需要使用符合要求的 SM2 签名证书和加密证书。thrift_ssl_client_auth 仅控制 Client RPC 的客户端证书认证，不影响 REST API 的 client_auth 配置，也不改变节点间通信的认证方式。

2. 协议选择

在 iotdb-system.properties 中使用 ssl_protocol 选择通信协议，默认值为 TLS。

如需确保连接仅使用国密协议，请将服务端和客户端均配置为 TLCPv1.1。使用 TLCP 时，连接可能回退到普通 TLS。

3. 服务端配置

3.1 客户端通信加密

在 DataNode 的 iotdb-system.properties 中启用 Client RPC 通信加密。默认情况下，客户端仅验证服务端证书：

enable_thrift_ssl=truessl_protocol=<protocol>key_store_path=/path/to/server.keystorekey_store_pwd=<key_store_password>

如需要求客户端提供证书，在上述基础上启用客户端认证，并配置用于验证客户端证书的 TrustStore：

enable_thrift_ssl=truethrift_ssl_client_auth=truessl_protocol=<protocol># 服务端私钥和服务端证书key_store_path=/path/to/server.keystorekey_store_pwd=<key_store_password># 信任客户端证书或签发客户端证书的 CAtrust_store_path=/path/to/server.truststoretrust_store_pwd=<trust_store_password>

完成配置后重启 DataNode。启用后，通过 dn_rpc_port 访问该 DataNode 的客户端必须开启 SSL，否则无法建立连接。

当 thrift_ssl_client_auth=false（默认值）时，行为与历史版本一致，客户端只需配置 TrustStore 来验证服务端证书。当 thrift_ssl_client_auth=true 时，服务端在 TLS 握手中要求客户端提供证书；客户端未提供证书、证书不受服务端 TrustStore 信任，或证书与私钥不匹配时，连接不可用。

thrift_ssl_client_auth 仅在 enable_thrift_ssl=true 时生效。它不复用 REST API 的 client_auth，因此修改其中任一开关不会影响另一种协议。

3.2 节点间通信加密

在所有参与集群内部通信的节点上配置：

enable_internal_ssl=truessl_protocol=<protocol>key_store_path=/path/to/node.keystorekey_store_pwd=<key_store_password>trust_store_path=/path/to/cluster.truststoretrust_store_pwd=<trust_store_password>

集群节点之间需要相互建立连接，因此每个节点都必须配置自己的 KeyStore，并通过 TrustStore 信任其他节点的证书。所有节点必须使用兼容的协议配置，并在 TrustStore 中导入为集群节点签发证书的 CA。

3.3 配置参数

4. 标准 TLS 通信

按照第 3 章启用通信加密，并在服务端和客户端配置兼容的 TLS 版本。然后准备服务端证书，并在客户端 TrustStore 中导入签发该证书的 CA 或服务端证书。如需启用 mTLS，还需要准备客户端证书，并在服务端 TrustStore 中导入客户端证书或签发该证书的 CA，具体配置见用户手册。

5. 国密通信加密

使用 TLCP 1.1 前，必须满足以下条件：

  • 使用腾讯 Kona JDK 启动服务端以及相关 Java 客户端，并确认该 JDK 支持 TLCP 1.1 和 SM2。

  • 服务端 KeyStore 必须使用 PKCS12 格式，并同时包含 SM2 签名证书及私钥、SM2 加密证书及私钥。

  • TrustStore 包含签发上述证书的 CA 证书。

  • 服务端和客户端将协议配置为 TLCPv1.1。

以下示例使用 tlcp-sign 和 tlcp-enc 作为证书别名；如果实际证书使用其他别名，请以 KeyStore 中的条目名称为准。

6. 故障排查