阿里云 InfluxDB® 版退市——TDengine 迁移技术指南

面向受阿里云 InfluxDB® 版退市影响的用户，TDengine 提供专属迁移咨询服务及优惠方案。扫描下方二维码，获取一对一迁移方案评估与专属优惠。

阿里云 TSDB for InfluxDB® 将于 2026 年 10 月 23 日正式退市。官方公告 显示，2025 年 10 月 23 日起已停止新购，2026 年 4 月 23 日起不再提供续费和扩容；退市后控制台关闭、实例释放，且不再提供技术支持。对仍以 InfluxDB 1.x 兼容接口写入、用 InfluxQL 查询的团队来说，真正要回答的是：数据怎么完整拿出来，写入链路改多少，查询怎么迁。

1. 为什么选择 TDengine 作为替代

针对阿里云 InfluxDB 的迁移场景，TDengine 的价值不仅在于承接数据，还在于降低切换风险，并提供后续业务演进所需的时序处理能力：

• 写入链路可分阶段切换：TDengine 提供 InfluxDB Line Protocol 写入端点。对于已使用该协议的应用或采集器，可以先双写到 TDengine、验证后再切换写地址，无须在第一阶段重写采集数据格式。
• 时序模型与 SQL 查询适配：经 Line Protocol 写入时，InfluxDB 的 measurement、tag 和 field 可分别映射为 TDengine 的超级表、标签列和普通列。TDengine 以”一设备一表”和超级表等模型组织时序数据，并使用标准 SQL 及时间序列扩展完成时间范围过滤、标签筛选、聚合、窗口计算、插值和最新值查询。
• 存储、规模与部署可按业务演进：TDengine 针对时序数据提供列式存储、压缩、按时间分区和水平扩展能力，适合持续增长的设备、监控和工业时序数据。实际存储占用、写入吞吐和查询时延可基于业务数据模型、数据量和硬件资源完成 PoC 验证。
• 处理与分发能力内置：除数据库读写外，TDengine 还提供缓存、流式计算和数据订阅能力。迁移后可逐步将实时聚合、降采样、告警前置和下游数据分发靠近数据完成。
• 迁移路径和生态可选择：TDengine Cloud、TDengine TSDB-OSS 与 TDengine TSDB-Enterprise 都可作为迁移目标，分别适配全托管、自建开源和私有化部署需求。标准 SQL、JDBC/ODBC 和多语言连接器也便于接入现有应用、BI 与可视化工具。

2. 迁移前评估、目标产品形态选择与总体切换策略

迁移前应完成源端盘点：

1. 数据库、保留策略和数据保留时长；
2. measurement、tag、field、字段类型和时间精度；
3. 写入客户端、采集器和认证方式；
4. 关键 InfluxQL 查询、报表、告警和接口；
5. 历史数据量、每日增量、最大基数和可接受切换窗口。

在开始迁移前选择一种目标产品形态。三种形态的 SQL、数据模型和迁移验收原则一致，但历史数据和实时接入路径不同：

目标产品形态	部署方式	历史数据迁移	实时写入	主要前提与适用场景
TDengine Cloud	阿里云上的全托管服务	Cloud InfluxDB 数据源，通过连接代理读取源端	Cloud InfluxDB Line Protocol 端点，使用 Cloud Token	希望保留阿里云使用体验、减少部署和运维；连接代理须能访问源 InfluxDB
TDengine TSDB-OSS	自建开源集群	按 Shard 备份并恢复至自建 InfluxDB 中继，导出 Line Protocol 后导入	自建 taosAdapter InfluxDB v1 端点	希望使用开源版本，并能够维护中继和目标集群
TDengine TSDB-Enterprise	私有化部署，可部署在本地或公有云	taosX / taosExplorer InfluxDB 数据源任务	自建 taosAdapter InfluxDB v1 端点	需要可视化数据源任务、持续同步或企业级部署能力

推荐采用「先保护增量、再回灌历史、最终追平后切读」的低风险流程。阿里云的 backup 只能覆盖备份时刻已有数据，无法自动包含迁移过程中的新增写入；因此不能在历史迁移完成后才启动双写或持续同步。

阶段	操作	预期结果
1. 建立目标端并确定边界	创建纳秒精度的 TDengine 数据库，记录历史迁移截止点 T0、写入和查询验收基线	目标端可接收测试数据，历史与增量范围明确
2. 保护增量	从 T0 开始启动应用双写；云服务和企业版也可创建不设置结束时间的持续同步任务	新增数据同时进入两端
3. 迁移历史	导入 T0 前的历史数据；云服务和企业版按时间范围同步，社区版按 Shard 导出后导入	历史数据按时间窗口逐步到达目标端
4. 最终追平	在切换窗口停止旧写入，完成最后一个增量窗口	时间边界和数据量对齐
5. 验收	核对记录数、最小/最大时间戳、抽样聚合和关键查询	关键业务结果一致或已确认差异
6. 切换读取	将读请求改为 TDengine SQL，并灰度发布	业务稳定运行
7. 下线旧链路	观察期结束且无数据差异后停止旧链路	迁移完成

3. 数据模型映射与写入语义

3.1 Line Protocol 映射

下表适用于写入 TDengine 的 InfluxDB Line Protocol。

InfluxDB Line Protocol	TDengine
measurement	超级表名称
tag key/value	标签列；标签值自动转换为 NCHAR
field key/value	普通列；按类型后缀或引号推断类型
timestamp	主键时间戳，默认列名为 _ts
measurement + tag set	子表；默认按排序后的 tag 计算 MD5 生成表名

例如，下面的 Line Protocol：

cpu,host=server01,region=cn-beijing usage=42.5,load=2i,status="ok" 1704067200000000000

会创建或使用名为 cpu 的超级表，将 host、region 作为标签列，将 usage、load、status 作为普通列，并以时间戳作为主键。

3.2 迁移时必须确认的语义

• 写入时应显式设置时间精度，并与纳秒精度的目标数据库保持一致；
• 同一 field 在不同数据行中使用冲突类型时，写入会失败；
• 未出现的字段或标签列会以 NULL 写入，模式只会增加，不会收缩；
• 单行最大长度为 64 KB，全部 tag 值总长度最大为 16 KB；
• 自动生成的子表名不可读；业务依赖可读表名时，应先验证子表命名配置或 table_name_key；
• 超级表和子表名称区分大小写；自动表名中的点号会替换为下划线；
• 无模式写入会自动创建超级表和子表，不要先手工创建同名超级表，否则可能导致写入异常。

4. 历史数据迁移

历史数据迁移分为云服务、企业版和社区版三条路径。无论选择哪条路径，都应先使用一个 measurement 和较小时间范围进行验证，再逐步扩大范围。

4.1 TDengine Cloud：通过 InfluxDB 数据源迁移或持续同步

TDengine Cloud 可在”数据写入”页面创建 InfluxDB 数据源，通过连接代理从源端读取并写入当前 Cloud 实例。连接代理必须运行在能够访问源 InfluxDB 的网络中；开始前需在 Cloud 实例中创建空的目标数据库。

创建数据源时，应逐项确认：

配置项	要求或建议
连接代理	部署在与源 InfluxDB 相同或可达的网络中
源端认证	InfluxDB 1.x 使用用户名和密码；该用户需要读取权限
连通性	提交前执行连通性检查
同步范围	选择需要迁移的 measurement；未选择时同步全部
时间范围	指定起始时间；结束时间可选，不填则持续同步
每次读取的时间范围	根据源端负载和数据密度调整，避免范围过大导致内存压力
延迟	设置合理延迟，以降低乱序数据影响

先在较小时间范围内验证数据模型、记录数和时间边界，再扩大同步范围。若源端位于阿里云 VPC，应在迁移前完成连接代理到源端和 Cloud 实例的网络连通性验证。

4.2 TDengine TSDB-Enterprise：通过 taosX 迁移或持续同步

企业版可在 taosExplorer 中创建 InfluxDB 数据源任务，由 taosX 从源端读取数据并写入 TDengine。该任务可用于历史迁移；不设置结束时间时，可持续同步新增数据。

创建任务时，应逐项确认：

配置项	要求或建议
目标数据库	使用纳秒精度数据库
源端认证	InfluxDB 1.x 用户名和密码；该用户需要读取权限
连通性	提交前执行连通性检查
同步范围	选择需要迁移的 measurement；未选择时会同步全部
时间范围	指定起始时间；结束时间可选，不填则持续同步
每次读取的时间范围	根据源端负载和数据密度调整，避免范围过大导致内存压力
延迟	设置 1～30 秒，以降低乱序数据影响

任务会将进度保存到磁盘；暂停、重启或异常恢复后不会从头开始。应先验证一个 measurement 和小时间窗口迁移后的表结构、记录数与时间边界，再扩大任务范围。

4.3 TDengine TSDB-OSS：导出 Line Protocol 后导入

taosAdapter 是数据写入接口，不会主动读取阿里云 InfluxDB 实例。因此，社区版的历史迁移需要先将源端数据导出为 InfluxDB Line Protocol，再写入 TDengine。

遵循阿里云 backup 路径时，需先满足其前提条件：源实例版本不低于 1.8.14、通过工单开通 8088 备份端口，并在相同地域、可用区、VPC 和交换机中准备自建 InfluxDB 1.x 中继。备份会消耗源端资源，阿里云要求源实例可用存储空间不低于 40%、内存水位不高于 60%；中继 ECS 建议预留至少两倍源数据量的可用空间。

建议按以下步骤执行：

1. 按 阿里云迁出方案，通过 SHOW SHARDS 获取真实 Shard 清单，并逐个执行 influxd backup、influxd restore 到自建 InfluxDB 1.x 中继；
2. restore 完成后等待数十秒，确认数据已从 WAL 落入数据目录，再用 influx_inspect export 导出 Line Protocol，并添加 -lponly，避免将 DDL 混入待写入数据；
3. 在隔离环境中选取一个 measurement 和一个小时间窗口，用 taosAdapter 分批写入目标 TDengine 数据库；批次报错时保留原始批次，并按已成功的时间窗口和失败批次重试；
4. 检查时间精度、字段类型、标签和自动创建的表结构；
5. 对每个时间窗口核对记录数、最小/最大时间戳和代表性聚合值，通过后再扩大迁移范围；
6. 持续保持应用双写，直至完成最终追平和读切换。

5. 实时写入链路切换：InfluxDB Line Protocol

5.1 TDengine Cloud：使用 Cloud InfluxDB Line Protocol 端点

TDengine Cloud 的 InfluxDB Line Protocol 写入端点为：

POST <TDENGINE_CLOUD_URL>/influxdb/v1/write?db=<TDENGINE_DATABASE>&token=<TDENGINE_CLOUD_TOKEN>&precision=ns

在 Cloud 实例中获取 URL 和 Token 后，可使用现有 Line Protocol 数据直接写入。示例：

curl --request POST 
  "$TDENGINE_CLOUD_URL/influxdb/v1/write?db=<TDENGINE_DATABASE>&token=$TDENGINE_CLOUD_TOKEN&precision=ns" 
  --data-binary 'cpu,host=server01,region=cn-beijing usage=42.5,load=2i,status="ok" 1704067200000000000'

Cloud Token 是 TDengine Cloud 的认证凭据，应通过环境变量、密钥管理服务或运行时注入提供，避免写入源码、脚本仓库或日志。

5.2 TDengine TSDB-OSS / Enterprise：使用自建 taosAdapter

taosAdapter 的 InfluxDB v1 写入端点为：

POST http://<TAOS_ADAPTER_HOST>:6041/influxdb/v1/write

请求中使用 db 指定 TDengine 数据库，使用 precision 指定时间精度。该 InfluxDB v1 写入接口支持 HTTP Basic Auth 和 URL 参数 u、p；TDengine TSDB-Enterprise 还支持通过 Authorization: Bearer <token> 传入 CREATE TOKEN 生成的 Bearer Token。上述 Token 不是 InfluxDB Token。生产环境应预先创建目标数据库并使用最小权限账号，避免将账号密码写入源码或日志。

以下是写入示例：

curl --request POST 
  "http://<TAOS_ADAPTER_HOST>:6041/influxdb/v1/write?db=<TDENGINE_DATABASE>&precision=ns" 
  --user "<TDENGINE_USER>:<TDENGINE_PASSWORD>" 
  --data-binary 'cpu,host=server01,region=cn-beijing usage=42.5,load=2i,status="ok" 1704067200000000000'

无论选择 Cloud 还是自建 taosAdapter，均应按以下步骤切换：

1. 先在非生产数据库发送一条包含数值、字符串、多个 tag 和纳秒时间戳的测试数据；
2. 使用 SQL 检查自动创建的超级表、标签列、普通列和读回数据；
3. 应用侧增加 TDengine 双写，持续对比写入错误率和数据延迟；
4. 双写稳定后，将主写入流量切至所选目标端；在观察期内保留旧写入链路；
5. 如果出现字段类型冲突、时间精度错误或写入异常，保留原始批次，并按已成功的时间窗口和失败批次重试。

6. 查询层改造：InfluxQL 到 TDengine SQL

无论选择 TDengine Cloud、TDengine TSDB-OSS 还是 TDengine TSDB-Enterprise，应用读请求都需要改写为 TDengine SQL，并针对窗口、填充和最新值语义完成回归验证。

InfluxQL 查询意图	TDengine SQL 方向
时间范围过滤	WHERE _ts >= ... AND _ts < ...
标签条件	WHERE tag_name = 'value'
MEAN、MAX、COUNT	AVG、MAX、COUNT
GROUP BY time(1m)	INTERVAL(1m)
GROUP BY tag	PARTITION BY tag_name、tbname
LAST(field)	LAST(field) 或 LAST_ROW(*)
fill(null/previous/linear)	FILL(NULL/PREV/LINEAR)

6.1 时间范围、标签筛选和窗口聚合

原始 InfluxQL 查询的意图是：查询 server01 在一分钟窗口内的平均 CPU 使用率。

SELECT MEAN("usage")
FROM "cpu"
WHERE time >= '2024-01-01T00:00:00Z'
  AND time < '2024-01-01T00:02:00Z'
  AND "host" = 'server01'
GROUP BY time(1m), "host"

可改写为 TDengine SQL：

SELECT _wstart AS window_start, host, AVG(usage) AS avg_usage
FROM migration_db.cpu
WHERE _ts >= '2024-01-01T00:00:00.000000000Z'
  AND _ts < '2024-01-01T00:02:00.000000000Z'
  AND host = 'server01'
PARTITION BY host
INTERVAL(1m);

时间条件采用左闭右开区间，避免相邻迁移窗口产生重复或遗漏。

6.2 按标签分组统计

原始 InfluxQL 查询的意图是：按区域统计指定时间段内的 CPU 最大值和样本数。

SELECT MAX("usage"), COUNT("usage")
FROM "cpu"
WHERE time >= '2024-01-01T00:00:00Z'
  AND time < '2024-01-02T00:00:00Z'
GROUP BY "region"

可改写为 TDengine SQL：

SELECT region, MAX(usage) AS max_usage, COUNT(usage) AS sample_count
FROM migration_db.cpu
WHERE _ts >= '2024-01-01T00:00:00.000000000Z'
  AND _ts < '2024-01-02T00:00:00.000000000Z'
GROUP BY region;

6.3 最新值与完整最新行

若业务需要同一条最新记录中的全部字段值，使用 LAST_ROW(*)：

SELECT LAST_ROW(*)
FROM migration_db.cpu
WHERE host = 'server01';

若只需某个字段或各字段最后一个非空值，TDengine 还可使用 LAST(expr) 或 LAST(*)。这比直接取最新行更适合字段可能缺失的场景。

6.4 最近 N 条原始数据

原始 InfluxQL 查询的意图是：查询某台主机最近的 10 条 CPU 数据。

SELECT "usage", "load"
FROM "cpu"
WHERE "host" = 'server01'
ORDER BY time DESC
LIMIT 10

可改写为 TDengine SQL：

SELECT _ts, usage, load
FROM migration_db.cpu
WHERE host = 'server01'
ORDER BY _ts DESC
LIMIT 10;

6.5 缺失值填充

对于窗口查询，可以使用 FILL(NULL)、FILL(PREV) 或 FILL(LINEAR) 指定填充策略。例如：

SELECT _wstart, AVG(usage)
FROM migration_db.cpu
WHERE _ts >= '2024-01-01T00:00:00.000000000Z'
  AND _ts < '2024-01-01T01:00:00.000000000Z'
  AND host = 'server01'
INTERVAL(1m)
FILL(PREV);

7. SQL 迁移后的能力扩展

完成写入和查询迁移后，TDengine 不只是承接原有 InfluxDB 工作负载，还可以把一些原先需要额外组件或定时任务完成的处理靠近数据完成。以下能力适用于所选目标产品形态，应在完成基础迁移和查询回归后逐步引入，而不是与切库同时上线。

7.1 流式计算：实时聚合、降采样和告警前置

流式计算可以在新数据写入后按窗口自动执行 SQL，并将结果写入目标表或发送通知。它可用于：

• 持续生成分钟级、小时级聚合结果，降低报表和大屏对明细数据的扫描量；
• 对阈值、状态或事件窗口进行实时计算，为告警服务提供输入；
• 将实时计算结果沉淀为独立表，供 API、BI 或后续查询直接使用。

例如，下面的流按 host 对 CPU 使用率按分钟聚合，并将每个窗口的平均值写入 cpu_usage_1m。

CREATE STREAM cpu_usage_1m_stream
  INTERVAL(1m) SLIDING(1m)
  FROM migration_db.cpu
  PARTITION BY host
  INTO cpu_usage_1m
  AS
    SELECT _twstart AS ts,
           AVG(usage) AS avg_usage
    FROM %%trows;

7.2 数据订阅：向下游实时分发数据

数据订阅可将主题中的新写入数据提供给下游消费者，减少业务通过定时查询轮询数据库的需求。主题可以基于查询、超级表或数据库定义；消费者可使用连接器 API、taos shell 或 MQTT 客户端接收数据，并通过消费组管理消费进度。

例如，为 CPU 数据创建只包含所需字段的查询主题：

CREATE TOPIC cpu_realtime_topic AS
SELECT tbname, _ts, usage, status
FROM migration_db.cpu;

告警服务、实时分析服务或数据同步程序可以消费 cpu_realtime_topic。查询主题不支持聚合和时间窗口；需要先聚合的数据，应先由流式计算写入结果表，再订阅该结果表。

7.3 虚拟表：按时间轴组合多表数据

虚拟表不直接存储数据。查询时，TDengine 从一个或多个真实表或已有虚拟表读取列，并按时间戳对齐生成结果。它适合将同一设备分散在多个 measurement 或表中的指标组合为统一查询入口，减少应用层的手工对齐和重复数据写入。

例如，某设备的 CPU 和环境数据分别落在两个物理子表中，可创建虚拟表统一读取：

CREATE VTABLE device_overview (
    ts TIMESTAMP,
    cpu_usage DOUBLE FROM migration_db.cpu_server01.usage,
    temperature FLOAT FROM migration_db.env_server01.temperature
);

查询 device_overview 时，两个来源表中相同时间戳的列会组合为同一行；仅某一来源存在的时间戳会保留，缺失列以 NULL 表示。虚拟表只能查询，不能写入或删除数据。示例中的 cpu_server01 和 env_server01 须替换为迁移后实际存在的物理表或子表。

8. 总结

阿里云 InfluxDB® 版退市带来了明确的迁移时间窗口。迁移至 TDengine 时，应将历史数据迁移、实时数据接入和查询改造作为一个完整流程实施：

• TDengine Cloud 可通过 InfluxDB 数据源和连接代理完成历史迁移或持续同步，也可使用 Cloud InfluxDB Line Protocol 端点承接实时写入；
• TDengine TSDB-OSS 通过「按 Shard 备份与恢复到自建 InfluxDB 中继 — 导出 Line Protocol — 经 taosAdapter 导入」的路径迁移历史数据，增量靠应用双写覆盖；
• TDengine TSDB-Enterprise 可通过 taosX 和 taosExplorer 的 InfluxDB 数据源任务完成历史迁移或持续同步，跨 VPC 时可能需配合 taosX-Agent；
• 应用查询需要从 InfluxQL 改写为 TDengine SQL，并验证窗口、填充和最新值语义；
• 应先保护增量数据，再回灌历史；通过最终追平、分窗口校验和灰度切读降低切换风险。

建议尽早使用代表性业务数据完成 PoC，并为历史回灌、增量追平和观察期预留充足时间。