Td单节点全备数据迁移至新版本的td单副本集群后，数据存储量增长了8倍多是什么原因?

TDuser_A2eA_4394 · 2025 年11 月 13 日 11:00

【TDengine 使用环境】
生产环境

【TDengine 版本】

3.0.5.0 –> 3.3.6.13

【操作系统以及版本】

cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

【部署方式】
非容器部署

【集群节点数】
1 → 3

【集群副本数】
1 → 1

【描述业务影响】

原先的TD为3.0.5.0版本的单节点，创建了3个database没指定默认使用的vgroups数量为2，后TD升级版本(新建的TD单副本集群): 在原3.0.5.0TD上 taodump导出全备数据传输迁移至3.3.6.13版本的其中一节点后，再通过taosdump导入TD集群。建库时VGROUPS根据每个Databases的表数量将原先的VGROUPS 2依次更改为8、4、3个，即原先6个VGROUPS更改为15个，KEEP 保存周期也从原先的60天更改为5年；全备数据taosdump导入后发现每个主机的数据节点的存储暴增！

【问题复现路径/shan】做过哪些操作出现的问题

原A、B、C数据库在create时没指定VGROUPS，默认为2；
后根据每个库下的表数量A B C库下依次有14w、3.5k、3.3k张表，建库时分别设置VGROUPS为8、4、3。

【遇到的问题：问题现象及影响】

#原数据目录
du -sh /var/lib/taos/
109G    /var/lib/taos/


#集群TD01
218G    /storage/taos/

#集群TD02
252G    /storage/taos/

#集群TD03
465G    /storage/taos/

数据分布不均的原因应该是VGROUPS在节点上分布不均导致的；但是数据量为什么会增加这么多？接近原先的8.5倍之多。

【资源配置】

#CPU
lscpu |grep -i cpu\(s\)
CPU(s):                4
On-line CPU(s) list:   0-3


#内存
free -m
              total        used        free      shared  buff/cache   available
Mem:           7551        2454         615           0        4480        4798
Swap:             0           0           0


#磁盘
df -Th
文件系统       类型      容量  已用  可用 已用% 挂载点
devtmpfs       devtmpfs  3.7G     0  3.7G    0% /dev
tmpfs          tmpfs     3.7G     0  3.7G    0% /dev/shm
tmpfs          tmpfs     3.7G  556K  3.7G    1% /run
tmpfs          tmpfs     3.7G     0  3.7G    0% /sys/fs/cgroup
/dev/vda1      ext4       50G  4.0G   43G    9% /
/dev/vdb1      ext4      498G  348G  126G   74% /storage
tmpfs          tmpfs     756M     0  756M    0% /run/user/0

klxu · 2025 年11 月 14 日 05:31

@TDuser_A2eA_4394

请看下 3 个节点 dataDir 目录下各个文件的大小，如果 3.0.5.0 还存在，也看下数据目录文件大小。例如，

find . -type f -exec du -h {} \;

TDuser_A2eA_4394 · 2025 年11 月 14 日 05:51

该集群环境因磁盘将近占满我销毁了，但是存储目录主要是/storage/taos/vnode目录。

为了验证是不是版本的问题，我用该3.0.5.0的全备数据导入到刚搭建的TD3.3.6.13版本的单节点中,仅仅是两个数据库已占用了194G

# 新建TD3.3.6.13版本单节点，只导入了A、B两个库的全备后，数据目录/storage/taos/的大小
[root@prod-tdengine ~]# du -sh /storage/taos/*
28K     /storage/taos/dnode
184K    /storage/taos/explorer
736K    /storage/taos/mnode
194G    /storage/taos/vnode

# 将数据目录下的占用从高到低排序，只显示前50
find . -type f -exec du -h {} \;|sort -hr|head -50
8.6G    ./vnode/vnode15/tsdb/v15f2038ver4.data
8.1G    ./vnode/vnode15/tsdb/v15f2037ver5.data
7.5G    ./vnode/vnode16/tsdb/v16f2038ver4.data
7.4G    ./vnode/vnode15/tsdb/v15f2036ver6.data
7.0G    ./vnode/vnode16/tsdb/v16f2037ver5.data
6.5G    ./vnode/vnode16/tsdb/v16f2036ver6.data
6.1G    ./vnode/vnode15/tsdb/v15f2039ver3.data
5.3G    ./vnode/vnode16/tsdb/v16f2039ver3.data
59M     ./vnode/vnode15/wal/00000000000000154124.log
59M     ./vnode/vnode15/wal/00000000000000151855.log
58M     ./vnode/vnode15/wal/00000000000000163856.log
58M     ./vnode/vnode15/wal/00000000000000161238.log
58M     ./vnode/vnode15/wal/00000000000000160097.log
58M     ./vnode/vnode15/wal/00000000000000151114.log
58M     ./vnode/vnode14/wal/00000000000000000000.log
57M     ./vnode/vnode16/wal/00000000000000124723.log
57M     ./vnode/vnode16/wal/00000000000000108939.log
57M     ./vnode/vnode15/wal/00000000000000155671.log
57M     ./vnode/vnode15/wal/00000000000000151451.log
57M     ./vnode/vnode15/wal/00000000000000151248.log
57M     ./vnode/vnode15/wal/00000000000000147207.log
57M     ./vnode/vnode15/wal/00000000000000143518.log
57M     ./vnode/vnode15/wal/00000000000000105291.log
56M     ./vnode/vnode16/wal/00000000000000162039.log
56M     ./vnode/vnode16/wal/00000000000000161182.log
56M     ./vnode/vnode16/wal/00000000000000148303.log
56M     ./vnode/vnode16/wal/00000000000000120038.log
56M     ./vnode/vnode15/wal/00000000000000162651.log
56M     ./vnode/vnode15/wal/00000000000000162188.log
56M     ./vnode/vnode15/wal/00000000000000160303.log
56M     ./vnode/vnode15/wal/00000000000000159233.log
56M     ./vnode/vnode15/wal/00000000000000158564.log
56M     ./vnode/vnode15/wal/00000000000000158497.log
56M     ./vnode/vnode15/wal/00000000000000158296.log
56M     ./vnode/vnode15/wal/00000000000000157685.log
56M     ./vnode/vnode15/wal/00000000000000156208.log
56M     ./vnode/vnode15/wal/00000000000000155069.log
56M     ./vnode/vnode15/wal/00000000000000154934.log
56M     ./vnode/vnode15/wal/00000000000000154664.log
56M     ./vnode/vnode15/wal/00000000000000153786.log
56M     ./vnode/vnode15/wal/00000000000000153652.log
56M     ./vnode/vnode15/wal/00000000000000152927.log
56M     ./vnode/vnode15/wal/00000000000000152658.log
56M     ./vnode/vnode15/wal/00000000000000150505.log
56M     ./vnode/vnode15/wal/00000000000000149569.log
56M     ./vnode/vnode15/wal/00000000000000149432.log
56M     ./vnode/vnode15/wal/00000000000000148485.log
56M     ./vnode/vnode15/wal/00000000000000146802.log
56M     ./vnode/vnode15/wal/00000000000000146735.log
56M     ./vnode/vnode15/wal/00000000000000145251.log


# 原3.0.5.0导出A、B两库全备数据的目录大小
du -sh A B
67G     B
91M     A


# 原3.0.5.0数据目录大小
du -sh /var/lib/taos/*
8.0K    /var/lib/taos/dnode
2.1M    /var/lib/taos/mnode
111G    /var/lib/taos/vnode

klxu · 2025 年11 月 14 日 08:13

@TDuser_A2eA_4394

.data 文件大小 56.5 G，那么剩余的主要是 wal 文件。之前 3.0.5.0 是逐步写入的，而导入过程有可能短时间内写入了大量数据和 wal 文件。其中，wal 目录中文件保存时长和大小受 WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 这两个 DB 参数的控制，建库时未指定后期也可以修改。可以确认下是否为该问题引起的。

参考查看数据库。

TDuser_A2eA_4394 · 2025 年11 月 14 日 08:18

的确，我也留意到这个问题了，因此将B库drop掉后重新建库时指定了WAL_RETENTION_SIZE 2097152，即2G大小，WAL_RETENTION_PERIOD 使用默认值即3600(一个小时)，然后重新导入全备数据观察一下是否是这个原因：

TDuser_0U66_0984 · 2025 年11 月 14 日 08:31

WAL_RETENTION_SIZE 不修改的话，是不是等WAL_RETENTION_PERIOD的时长，会自动清除WAL文件？

TDuser_A2eA_4394 · 2025 年11 月 14 日 09:16

* WAL_RETENTION_PERIOD: 为了数据订阅消费，需要WAL日志文件额外保留的最大时长策略。WAL日志清理，不受订阅客户端消费状态影响。单位为 s。默认为 3600，表示在 WAL 保留最近 3600 秒的数据，请根据数据订阅的需要修改这个参数为适当值。

通过官网查询到的解释是这样的：数据库 | TDengine 文档 | 涛思数据

TDuser_A2eA_4394 · 2025 年11 月 14 日 09:17

通过配置taos.cfg，添加了以下配置：
maxVgroupsPerDb       10
minTablesPerVnode     10000
tableIncStepPerVnode  5000


并且在创建B库时指定了WAL_RETENTION_SIZE 2097152，即2G大小后，目前导入数据后的数据目录大小为
du -sh /storage/taos/*
28K     /storage/taos/dnode
240K    /storage/taos/explorer
892K    /storage/taos/mnode
45G     /storage/taos/vnode

确实有效果，比原先没设置WAL_RETENTION_SIZE前 194G /storage/taos/vnode 小很多。

但是还发现一个问题：

find /storage/taos -name "*.log" | wc -l
120

find /storage/taos/vnode/ -type f -name "*log" -exec du -ch {} + 2>/dev/null | tail -1
4.1G    总用量

我是不是可以理解即使配置了WAL_RETENTION_SIZE 2097152，即2G大小，但是实际产生的log日志大小还是会超出该限制?

klxu · 2025 年11 月 14 日 09:48

这几个参数是 2.0 的，3.0 已经不适用了。

WAL_RETENTION_SIZE 是以 vnode 为单位进行统计处理的。

klxu · 2025 年11 月 14 日 09:55

@TDuser_0U66_0984 会的，但在 vnode commit 时才会触发。正常写入时，一般会触发 commit 并进行清理；如果没有写入动作了，可以执行 flush database {db_name}; 手动触发清理。

TDuser_A2eA_4394 · 2025 年11 月 17 日 05:58

多问一句：原先3.0.5.0版本的单节点TD /var/lib/taos/数据目录大小如下：

du -sh /var/lib/taos/*
8.0K    /var/lib/taos/dnode
2.0M    /var/lib/taos/mnode
118G    /var/lib/taos/vnode

将其中A、B、C数据库分别通过taosdump全备并以数据库名称命名的目录大小如下：

67G     /storage/20251104/B
91M     /storage/20251104/A
63G     /storage/20251105/C

————————————————————————————————————————————
新建3.3.6.13版本的单节点TD分别以下面的方式建库A、B、C(先前3.0.5.0上建库都未指定Vgroups默认使用的2且未设置WAL_RETENTION_SIZE)并分别导入先前的全备数据后显示：

CREATE DATABASE IF NOT EXISTS B 
REPLICA 1 DURATION 14400m KEEP 4204800m,4204800m,4204800m
PRECISION 'ms' MINROWS 100 MAXROWS 4096 COMP 2
VGroups 6 WAL_RETENTION_SIZE 2097152;

CREATE DATABASE IF NOT EXISTS C 
REPLICA 1 DURATION 14400m KEEP 4204800m,4204800m,4204800m
PRECISION 'ms' MINROWS 100 MAXROWS 4096 COMP 2
VGroups 6 WAL_RETENTION_SIZE 2097152;


CREATE DATABASE IF NOT EXISTS A 
REPLICA 1 DURATION 14400m KEEP 4204800m,4204800m,4204800m
PRECISION 'ms' MINROWS 100 MAXROWS 4096 COMP 2
VGroups 3 WAL_RETENTION_SIZE 2097152;


78G     /storage/taos/vnode

目前新版本的数据目录78G比原先3.0.5版本的数据目录小了40G,我可以理解为是新版本的TD以更优化的方式组织并压缩数据了么？

klxu · 2025 年11 月 17 日 07:20

有部分优化，但是不确定是否为优化的结果。首先要对比下两个版本 vnode wal 和 tsdb 两个目录的大小。