【TDengine 使用环境】预生产环境
【TDengine 版本】3.3.6.13
【操作系统以及版本】redhat 8.7
【部署方式】非容器部署
【集群节点数】3
【集群副本数】3
【描述业务影响】无法查询数据。
【问题复现路径/shan】
【遇到的问题：问题现象及影响】3个节点的服务器异常关机重启后，taosd可以启动，dnode、mnode都正常，但是无法查询数据。集群启动几个小时后，会有2个节点宕机，只剩一个节点在运行。
【资源配置】8核16G
【报错完整截图】（不要大段的粘贴报错代码，论坛直接看报错代码不直观）
05/28 19:01:47.420262 00051265 C UTL ERROR [rsync] stop rsync server failed,errno:2,msg:No such file or directory
05/28 19:01:47.923266 00051265 C UTL ERROR [rsync] cmd:rsync --daemon --port=873 --config=/var/lib/taos/backup/checkpoint/rsync.conf start server failed, code:32512,errno:0,msg:Success
05/28 19:01:49.699105 00051466 C TDB ERROR tdb/btc-upsert: btree encode cell failed with ret: -2147483368.
05/28 19:01:49.699110 00051466 C TDB ERROR tdb/btree-insert: btc upsert failed with ret: -2147483368.
05/28 19:01:49.699114 00051466 C MTA ERROR vgId:32, metaHandleChildTableCreateImpl failed at /root/tdengine/source/dnode/vnode/src/meta/metaEntry2.c:1331 since Invalid parameters, version:1219267 type:2 uid:4405941084284957422 name:oneesg_value_9977a7717b182663b599a89015153a60
05/28 19:01:49.699119 00051466 C MTA ERROR vgId:32, metaHandleChildTableCreate failed at /root/tdengine/source/dnode/vnode/src/meta/metaEntry2.c:1389 since Invalid parameters, version:1219267 type:2 uid:4405941084284957422 name:oneesg_value_9977a7717b182663b599a89015153a60
05/28 19:01:49.699123 00051466 C MTA ERROR vgId:32, metaHandleEntry2 failed at /root/tdengine/source/dnode/vnode/src/meta/metaEntry2.c:2541 since Invalid parameters, version:1219267 type:2 uid:4405941084284957422 name:oneesg_value_9977a7717b182663b599a89015153a60
05/28 19:01:49.699132 00051466 C MTA ERROR vgId:32, metaCreateChildTable failed at /root/tdengine/source/dnode/vnode/src/meta/metaTable2.c:407 since Invalid parameters, uid:4405941084284957422 name:oneesg_value_9977a7717b182663b599a89015153a60 suid:4403859238535214345 version:1219267
05/28 19:01:49.699136 00051466 C VND ERROR vgId:32 failed to create table:oneesg_value_9977a7717b182663b599a89015153a60, code:Invalid parameters
05/28 19:01:49.699144 00051466 C VND ERROR vgId:32, process submit request failed since Invalid parameters, ver:1219267
根据您提供的日志，TDengine在创建子表oneesg_value_9977a7717b182663b599a89015153a60 时失败，并伴随rsync服务启动/停止错误。以下为问题分析和解决建议。
错误摘要
- rsync服务异常
- 停止rsync服务失败：
No such file or directory （可能PID文件缺失）
- 启动rsync服务失败：退出码32512（通常表示命令未找到或配置错误）
- TDengine内部错误
- Btree编码/插入失败（
ret: -2147483368 ）
- 元数据创建子表失败：
Invalid parameters
- vgroup 32创建表失败
根因分析
- rsync问题 ：TDengine备份/恢复依赖rsync服务，其配置文件
/var/lib/taos/backup/checkpoint/rsync.conf 可能不存在或rsync未正确安装。但这属于辅助功能，不影响核心数据库写入。
- 核心错误 ：创建子表时参数无效。可能原因：
- 子表的列数、类型或标签与超级表（suid:
4403859238535214345 ）不匹配。
- Btree编码失败可能是由于表schema中包含不支持的字符或长度超限。
- 元数据版本（version:1219267）冲突或损坏。
- 磁盘空间不足或文件系统错误导致元数据写入失败。
解决方案
1. 检查表定义
确认创建子表的SQL语句是否与超级表完全一致，例如：
sql
– 查看超级表结构 DESCRIBE your_super_table_name; – 检查子表标签值类型是否正确
重点核对：
- 普通列的数量和类型
- 标签（TAG）的数量和类型（如int、varchar长度）
- 表名是否合法（无特殊字符）
2. 检查rsync服务（可选）
如果不需要备份功能，可忽略rsync错误。若需要：
bash
#确认rsync已安装 which rsync # 检查配置文件是否存在 ls -l /var/lib/taos/backup/checkpoint/rsync.conf # 手动启动rsync测试 rsync --daemon --port=873 --config=/var/lib/taos/backup/checkpoint/rsync.conf
根据缺失文件进行创建或修复。
3. 检查TDengine vgroup状态
sql
– 查看vgroup 32的健康状态 SHOW VGROUPS; – 查看该vgroup对应的数据库 USE your_database; SHOW TABLES;
如果vgroup异常，可能需要重启dnode或重新平衡副本。
###4. 检查磁盘和日志
bash
#检查磁盘空间 df -h # 查看TDengine详细日志 tail -f /var/log/taos/taosd.log
特别关注/root/tdengine/source/... 路径（但那是源码路径，实际需查看运行时日志）。
5. 临时规避方案
如果该子表可重建，尝试：
- 删除原有失败的表（如果存在残留元数据）
- 重新执行创建语句，确保参数正确。
若问题持续，建议：
- 升级TDengine到最新稳定版（可能修复了btree编码bug）
- 联系TDengine官方技术支持，提供完整日志和错误码
-2147483368 的解析。
注意事项
- 错误中的
oneesg_value_9977a7717b182663b599a89015153a60 表名长度正常，但检查是否包含不可见字符。
- rsync错误码32512通常表示
rsync: command not found ，确认rsync是否在PATH中且可执行。
如提供更多上下文（超级表结构、创建表的SQL、TDengine版本， show dnodes, show vnodes, 以及更多的taosd日志），可进一步精确定位。
现在集群状态是正常的，就是不能查询超级表的数据。
taos> show dnodes;
id | endpoint | vnodes | support_vnodes | status | create_time | reboot_time | note |
1 | test-tdengine-01.glp-inc.cn... | 19 | 20 | ready | 2025-12-09 13:46:23.266 | 2026-05-29 11:41:32.046 | |
2 | test-tdengine-02.glp-inc.cn... | 18 | 20 | ready | 2025-12-09 13:53:33.635 | 2026-05-29 14:42:53.768 | |
3 | test-tdengine-03.glp-inc.cn... | 18 | 20 | ready | 2025-12-09 13:53:37.934 | 2026-05-29 14:42:58.016 | |
Query OK, 3 row(s) in set (0.002622s)
有没有什么办法能暂时把数据导出来，我重新部署集群再还原回去么？
可以试一下用taosdump工具把数据库备份出来。
超级表中有一个特殊的数据类型，taosdump备份暂时不支持，之前都是用csv文件备份的。
应该是有部分子表损坏了，有的能查询，有的不行。有没有办法把损坏的子表批量找出来。
你可以写一个shell脚本，查询一下所有子表第一条数据，能查出来的就是正常的，查不出或者有报错的，就是异常的。
异常的子表，有什么办法修复么？或者能否以某个节点的数据为准，同步到其他节点，舍弃几分钟的数据，让整个集群可用。
你的数据量有多大啊，现在你也无法以某个节点的数据为主，因为你不知道这个子表坏在哪个节点上面。你刚才说的taosdump不能导出哪个类型的数据字段呢？
3.3.6.13版本的TDEngine中，taosdump还没有支持DECIMAL数据类型，这个以前在社区问过了。