不停机迁移，TDengine 在 3D 打印技术中的“焕新”之路

小T导读：自 2021 年我们正式使用 TDengine 至今已接近三年，现在 TDengine 已经成熟应用于我们多个项目当中，凭借着强大的读写存储能力，为我司多项业务的核心数据保驾护航。近期我们团队刚好完成 TDengine 2.x 到 3.x 的数据迁移，借此机会将 TDengine 的使用/迁移经验与大家分享。

选型过程及业务背景

我司的主要业务之一就是基于 3D 打印技术给客户提供整体化解决方案，其中一个核心场景是我们要持续追踪设备的运行状态，存储海量的设备运行数据。这是一个典型的物联网系统的核心需求——以设备为维度，按照时间顺序大批量写入和查询设备的各项数据。

这个业务场景非常适合时序数据库（Time Series Database，TSDB），但市场上的时序数据库存在着各种各样的痛点：或是数据读写性能不佳；或是部署的复杂性高，或是难以维护。经过多方考察对比后，我们发现 TDengine 是最适合我们的选择。

从 2.x 到 3.x，TDengine 在黑格智能 3D 打印业务的应用实践 - TDengine Database 时序数据库

TDengine 迁移过程

为顺利升级到 TDengine 3.x 版本，我们先把数据从 2.x 抽出写入到了一个 3.x 版本的临时集群，验证无误之后，再利用如下方案实现了无需停机、不影响业务写入的 3.x 版本之间的数据库迁移工作。过程如下：

a. 新增节点D\E\F：

CREATE DNODE "D";
CREATE DNODE "E";
CREATE DNODE "F";

b. 逐个删除节点A\B\C（以 A 为例）：

#删除A节点MNODE角色
DROP MNODE ON DNODE A_DNODE_ID;

#添加D节点MNODE角色
CREATE MNODE ON DNODE D_DNODE_ID;

#删除A节点，节点A删除过程，节点A的数据会同步到接口D\E\F中
DROP DNODE A_DNODE_ID;

典型业务场景分享

由于一台设备每天有数以万计的数据需要存储，世界各地范围内的设备汇集起来，便产生了海量的数据存储和查询需求。关于 TDengine ，我们主要有以下三个方向的应用：

在设备运行出现问题时，根据消息定位具体的问题；
以设备长时间运行的数据作数据分析，解决设备运行存在的隐患；
生成 BI 报表，展示设备各种传感器最近一段时间的状态。

从众多的超级表中，我们取一个百亿级别的超级表来举例说明 TDengine 的应用过程，具体表结构如下：

从 2.x 到 3.x，TDengine 在黑格智能 3D 打印业务的应用实践 - TDengine Database 时序数据库

当我们对这张设备消息表 s_mqtt 查询 ‘2023-12-15 00:00’ 至 ‘2023-12-15 02:50:00’ 时间段的 ‘1011’ 类型，设备序列号为 ‘xxxxxxx’ 的所有消息内容，可以看到，查询结果是毫秒级返回的：

select * from s_mqtt where ts>'2023-12-15 00:00:00.000' and ts<'2023-12-15 03:00:00.000' and device_sn='xx' and kind=1011 ;

从 2.x 到 3.x，TDengine 在黑格智能 3D 打印业务的应用实践 - TDengine Database 时序数据库

TDengine 高效的写入和读取性能很好的满足了我们频繁写入和读取数据的迫切需要。而在存储方面，压缩率经过计算在 10% 左右，也完全符合我们的存储需求。

遇到的问题

在 2.x 升级到 3.x 的过程中，我们遇到了以下两个比较棘手的问题，得到了 TDengine 官方技术团队的技术讲解和远程排查问题等支持，在此衷心表达感谢。

1. vgroups 设置问题。TDengine 3.x 版本增加了 vgroups 参数，代表了数据库读写数据的一个并行度，合理的设置可以最大程度的激发读写性能。我们在测试环境测试时，发觉表的读写比 2.x 版本慢了好多，经 TDengine 技术团队排查，发现我们只使用了默认的 2 个 vgroups，具体使用规则可以参考参考《体验 TDengine 3.0 高性能的第一步，请学会控制建表策略》。

2. taosAdapter 无返回问题。在 TDengine 3.x 版本上线后，微服务通过 restful 方式连接 TDengine 时，taosAdapter 会出现无响应但 taosd 服务正常的现象。这个问题我们自己排查了好久，后面寻求官方技术团队的帮忙，经过远程排查服务器环境和日志分析，最后定位到是我们大量使用”show cluster alive”作为微服务监听语句的频繁请求导致。随后官方建议我们更换”select 1″作为健康检查语句，顺利解决了这个问题。后续官方也优化了”show cluster alive”这个命令的实现，避免类似情况出现。