Apache IoTDB V1.3.7 版本解析：稳定性加固与配置变更
8 min
写在前面
Apache IoTDB V1.3.7 与 V2.0.7 于 2026-03-04 同一天发布，但这两个版本的定位和目标用户完全不同：
- V2.0.7：推荐版本，支持 Table 模型、MATCH RECOGNIZE 等新功能
- V1.3.7：面向现有 1.3.x 用户，不需要表模型、不希望引入更多变化的场景
目前社区的开发重心已转向 2.x 系列，1.3.x 主要接收 bug 修复和安全补丁。对于仍在使用 1.3.x 的用户，这篇文章回答几个关键问题：
- 1.3.7 修复了什么？为什么必须升级？
- 1.3.x 和 2.x 的功能差距有多大？
- 是升级 1.3.7 还是直接迁移 2.x？
- 生产环境如何零停机升级？
本文内容参考了 Apache IoTDB 公众号发布说明 及 GitHub Release Notes。
1.3.x 系列的定位
版本定位
IoTDB 版本路线图
1.3.0 ──→ 1.3.4 ──→ 1.3.5 ──→ 1.3.6 ──→ 1.3.7
│ │ │ │ │
│ │ │ │ └── 安全加固 + RPC 变更
│ │ │ │
│ │ │ └─────── CVE 修复 + 性能优化
│ │ │
│ │ └────────────── 功能增强
│ │
│ └──────────────────────── 早期生产版
│
└───────────────────────────────── 首个稳定版
2.0.0 ──→ 2.0.5 ──→ 2.0.6 ──→ 2.0.7
│ │ │ │
│ │ │ └── 安全加固 + RPC 变更
│ │ │
│ │ └────────────── MATCH RECOGNIZE + CVE 修复
│ │
│ └──────────────────────── 窗口函数 + JOIN 增强
│
└───────────────────────────────── Tree-Table 双模型1.3.x 的特点：
- 纯 Tree 模型（无 Table 模型）
- 经过长期生产验证
- API 和配置稳定
- 社区支持周期长
适合场景：
- 工业 IoT 数据采集（稳定优先）
- 已有大量 Tree 模型查询逻辑
- 运维团队技术栈保守
- 无法承担升级风险的生产环境
V1.3.7 核心变更分析
变更概览
| 类别 | 变更内容 | 影响等级 |
|---|---|---|
| 安全加固 | 移除高风险 RPC 接口 | 高 |
| 配置变更 | RPC 默认地址改为 127.0.0.1 | 高（集群部署必须注意） |
| 功能移除 | 移除 JEXL 函数 | 中 |
| 服务绑定 | 内部服务绑定到 dn_internal_address | 中 |
| Pipe | 创建 Pipe 时增加命名检查 | 低 |
| Bug 修复 | 分区表 TTL 删除逻辑 | 中 |
注意：CVE-2025-12183、CVE-2025-66566、CVE-2025-11226 已在 v1.3.6 中修复。如果你还在使用 v1.3.5 或更早版本，升级到 v1.3.7 可以同时获得 CVE 修复和本次安全加固。
重点一：RPC 默认地址变更（升级必坑）
变更内容
# 1.3.6 及之前
dn_rpc_address=0.0.0.0
# 1.3.7
dn_rpc_address=127.0.0.1 # 默认只监听本地对 1.3.x 用户的影响
场景一：单机部署（无影响）
# 本地 CLI 连接
./sbin/start-cli.sh
# 连接 127.0.0.1:6667，没问题场景二：集群部署（必须修改配置）
错误示范（升级后无法连接）：
# 用户直接替换二进制文件，未修改配置
$ ./sbin/stop-datanode.sh
$ # 替换为 1.3.7
$ ./sbin/start-datanode.sh
# 然后从其他机器连接
$ ./sbin/start-cli.sh -h 192.168.1.10
# Error: Connection refused!
# 原因：1.3.7 默认监听 127.0.0.1，不接受外部连接正确升级流程：
# 1. 升级前修改配置
$ vim conf/iotdb-conf.properties
# 修改为：
dn_rpc_address=192.168.1.10 # 本机实际 IP
dn_internal_address=192.168.1.10
# 2. 停止服务
$ ./sbin/stop-datanode.sh
# 3. 替换二进制
$ wget https://dlcdn.apache.org/iotdb/1.3.7/apache-iotdb-1.3.7-bin.tar.gz
$ tar -xzf apache-iotdb-1.3.7-bin.tar.gz
# 4. 启动服务
$ ./sbin/start-datanode.sh
# 5. 验证
$ ./sbin/start-cli.sh -h 192.168.1.10
# 连接成功！场景三：Docker 部署（需更新配置）
# docker-compose.yml
services:
iotdb:
image: apache/iotdb:1.3.7
ports:
- "6667:6667"
environment:
- IOTDB_DN_RPC_ADDRESS=0.0.0.0 # 容器内需要监听所有接口
- IOTDB_DN_INTERNAL_ADDRESS=iotdb重点二：移除 JEXL 函数
影响评估
JEXL 在实际使用中并不常见。主要原因：
- 大多数查询用内置函数就够了
- 复杂计算通常在客户端处理
- JEXL 性能不如编译型 UDF
替代方案
| 原 JEXL 用法 | 1.3.7 替代方案 |
|---|---|
JEXL('value * 2') | 内置算术：value * 2 |
JEXL('sin(value)') | 内置函数：sin(value) |
| 复杂业务逻辑 | 自定义 UDF（Java 编译） |
| 数据转换 | 客户端预处理 |
升级前检查
# 扫描查询日志中的 JEXL 使用
grep -i "JEXL" /path/to/query/logs/*.log
# 统计使用频率
grep -c "JEXL" /path/to/query/logs/*.log | awk -F: '{sum+=$2} END {print sum}'1.3.7 vs 2.0.7 功能对比
| 特性 | 1.3.7 | 2.0.7 |
|---|---|---|
| 数据模型 | Tree only | Tree + Table |
| 查询语言 | SQL (Tree) | SQL (双模型) |
| MATCH RECOGNIZE | 不支持 | 支持 |
| Table 模型聚合 | 不支持 | 支持 |
| 窗口函数 | 基础 | 增强（v2.0.5 新增） |
| UDF | 基础 | 增强（UDTF，v2.0.4 新增） |
| 安全加固 | 本次更新 | 本次更新 |
| 生产验证 | 充分 | 较充分 |
| 社区支持周期 | 长 | 中 |
决策指南：升级 1.3.7 还是迁移 2.x？
1.3.x 已进入维护模式
这是关键信息：
- 1.3.x 不再有新功能（Table 模型、MATCH RECOGNIZE 等都没有）
- 仅有安全修复和关键 bug 修复
- 社区开发重心已转向 2.x
选择 1.3.7 的场景（仅限特殊情况）
你的情况：
□ 生产环境已稳定运行 1.3.x 多年
□ 大量查询逻辑深度绑定 Tree 模型
□ 短期内（1-2 年）无法进行任何变更
□ 仅需安全修复，不需要新功能
→ 建议：升级到 1.3.7（临时方案），但应规划 2.x 迁移选择 2.x 的场景（推荐）
你的情况：
□ 新建项目（100% 推荐）
□ 现有 1.3.x 项目，可安排升级计划
□ 需要 Table 模型（关系型查询）
□ 需要 MATCH RECOGNIZE（流式分析）
□ 希望获得持续的功能更新和社区支持
→ 建议：直接部署 2.0.7 或规划迁移到 2.x迁移路径建议
| 场景 | 推荐 | 理由 |
|---|---|---|
| 新项目 | 2.0.7 | 1.3.x 已停止新功能 |
| 1.3.x 生产环境 | 规划迁移 2.x | 1.3.x 进入维护模式，迟早要迁移 |
| 无法立即迁移 | 1.3.7 临时过渡 | 仅用于安全修复，同时规划迁移 |
| 测试/开发环境 | 2.0.7 | 直接使用最新版本 |
核心观点：1.3.7 是”临时止痛药”，2.x 才是”长期解决方案”。 除非有无法克服的限制，否则应该选择 2.x。详细的迁移步骤请参考 Apache IoTDB 从 1.3.x 迁移到 2.x 完整指南。
生产环境升级实战（1.3.6 → 1.3.7）
升级前检查清单
# 1. 检查当前版本
$ ./sbin/start-cli.sh -v
# 2. 检查集群状态
IoTDB> show datanodes;
# 3. 检查配置
$ grep -E "rpc_address|internal_address" conf/iotdb-conf.properties
# 4. 检查 JEXL 使用情况
$ grep -r "JEXL" /path/to/queries/
# 5. 备份
$ cp -r data/ data.backup.$(date +%Y%m%d_%H%M%S)
$ cp -r conf/ conf.backup.$(date +%Y%m%d_%H%M%S)滚动升级步骤（零停机）
# ========== 节点 A (192.168.1.10) ==========
# 1. 修改配置（在升级前！）
$ vim conf/iotdb-conf.properties
dn_rpc_address=192.168.1.10
dn_internal_address=192.168.1.10
# 2. 停止 DataNode
$ ./sbin/stop-datanode.sh
# 3. 备份
$ cp -r data/ /backup/data.nodeA.$(date +%Y%m%d)
# 4. 替换二进制
$ wget https://dlcdn.apache.org/iotdb/1.3.7/apache-iotdb-1.3.7-bin.tar.gz
$ tar -xzf apache-iotdb-1.3.7-bin.tar.gz
$ cp -r apache-iotdb-1.3.7/* /path/to/iotdb/
# 5. 启动
$ ./sbin/start-datanode.sh
# 6. 验证
$ ./sbin/start-cli.sh -h 192.168.1.10
IoTDB> show datanodes; # 确认节点状态
# ========== 节点 B (192.168.1.11) ==========
# 重复上述步骤（一次升级一个节点）升级后验证
# 1. 版本检查
$ ./sbin/start-cli.sh -v
# 2. 基本查询测试
IoTDB> SELECT count(*) FROM root.**;
# 3. 写入测试
IoTDB> INSERT INTO root.sg.d1(time, s1) VALUES (now(), 123);
# 4. 日志检查
$ tail -100 log/iotdb.log | grep -E "ERROR|WARN"
# 应无异常