10TB、20天、公有云接力：一次时序数据库 IoTDB 数据迁徙的真实复盘
当机房搬迁遇上时序数据库，我们把时序文件格式 TsFile 玩成了「数据快递」。https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004153763-237846125.png
一、配景：搬迁来了，数据不能丢
我们的业务场景是典范的时序数据：大量装备连续上报传感器数据，写入 IoTDB 1.3.3 集群。原集群摆设在公司机房，接纳 3C3D 单副本架构。
公司搬迁关照下来后，原机房须要团体停机，预计窗口 20 天。这期间站端数据收罗不能停，于是我们做了一个暂时决议：
焦点计谋
[*]搬迁期间：站端数据切到公有云暂时节点，继承写入；
[*]搬迁竣过后：把公有云积累的 TsFile 搬回原机房新摆设的 IoTDB 集群。
听上去只是「暂时存一下、搬归去」，但现实数据量到了近 10TB，任何一个环节没控制好，都会让回迁变成灾难。
二、20 天时间线
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004200652-1387751963.png
三、架构演进：四个阶段
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004205702-1234967199.png
四、方案对比：为什么选 TsFile 搬迁
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004213402-1533930343.png
五、关键决议与数据
决议 1 - 单副本 3C3D，低落搬迁复杂度
原集群就是单副本，搬迁时如果改为多副本，会引入跨节点同步和同等性题目。我们保持 data_replication_factor=1 和 schema_replication_factor=1，让 node1 的数据始终回到 node1，制止分片肴杂。
决议 2 - 压缩：pigz 多线程是刚需
tar cf - sequence/ unsequence/ | pigz -p 16 > /data/iotdb_migrate/node_data.tar.gz
find /data/iotdb/data/datanode/data/ -type f \( -name '*.resource' -o -name '*.mods' \) | \
tar czf /data/iotdb_migrate/node_meta.tar.gz -T -履历：数据包里必须包罗 .resource 和 .mods。前者是索引，后者记录删除标志，漏带会让 load 重修索引或丢失删除利用。
决议 3 - 传输：xargs 并行 scp
ssh root@node "ls -1 /data/iotdb_migrate/*.tar.gz" | \
xargs -P 6 -I {} scp root@node:{} /data/backup_from_ssd/单线程 scp 吃不满带宽，用 xargs -P 6。
决议 4 - load 参数：-tn 6、-os none、-of none
./load-tsfile.sh -h 127.0.0.1 -p 6667 -u root -pw root \
-s /data/backup_from_ssd/tsfile_data/sequence/ \
-tn 6 -os none -of none> /data/load_errors/load_se.loghttps://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004220697-1357442069.png
六、真实踩坑
坑 1：压缩/解压时间远超预期
第一次预估时只算了网络传输时间，没把压缩、解压、load 的 I/O 开销算进去。现实上，HDD 上的解压和 load 由于随机 I/O 多，耗时比 SSD 高一个数目级。
教导：缓冲时间至少预留 50% 以上，HDD 不适相助为高性能 load 目的。
坑 2：HDD 上 cross space compaction 拖垮写入
HDD 暂时集群 load 数据后，cross space compaction 一启动，随机 I/O 直接把写入压到靠近停滞。厥后关闭 cross space compaction、调解 schedule interval 才缓解。
enable_seq_space_compaction=true
enable_unseq_space_compaction=false
enable_cross_space_compaction=false
compaction_schedule_interval_in_ms=60000坑 3：load 失败后的重试查抄
load 不是 100% 一次性乐成，失败日记和拒绝日记混在一起，人工筛查服从低。我写了一个 check_retry.sh，从拒绝日记中提取 TsFile，联合乐成日记判定哪些文件须要重试。通过比对发现，load 脚本会主动重试初次加载失败的 TsFile 文件。不外比对过才知道，是不是全部的 TsFile 都被乐成加载了。
grep -oP 'root\.+\.tsfile' "$REJECT_LOG" | sort | uniq -c | \
while read -r count tsfile; do
if [ "$count" -gt 1 ]; then
echo "[$count 次] $tsfile" >> "$NO_ONLY"
else
if grep "Processed success" "$LOAD_LOG" | grep -q "$tsfile"; then
echo "$tsfile" >> "$NO_NEED_RETRY"
else
echo "$tsfile" >> "$NEED_RETRY"
fi
fi
done输出三份清单：重复不唯一、已乐成无需重试、须要重新加载。用清单驱动重试，比逐行看日记靠谱。
坑 4：路径用相对路径导致 file not found
load 下令要求绝对路径。有一次为了省事用了相对路径，效果远端节点的工作目次差别等，报 file not found。厥后全部 load 下令同一用绝对路径。
坑 5 database 未提前创建
新 SSD 集群摆设后，没有提前创建与原集群同等的 database，导致 load 报 database 不存在。如今我们把「创建 database」写进了前置查抄清单。
七、验证：怎么才算「搬完了」
数据迁徙不能只靠「下令跑完」，必须做四层验证：
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004228394-738613491.png
八、复盘与发起
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004234138-1883425262.png
https://img2024.cnblogs.com/blog/3626153/202606/3626153-20260622004239267-1815951384.png
九、写在末了
这次迁徙让我印象最深的一点是：时序数据库的搬迁，拼的不是某一个参数，而是流程的完备度。
当你面临近 10TB 数据、400 亿+ 时序点、20 天停机窗口时，任何一个环节的遗漏都会被放大。提前写好脚本、预留缓冲时间、做好验证清单，才气让一次「数据快递」安全送达。
对于 IoTDB 的使用仍在不绝的学习中，接待各人交换分享！
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.
页:
[1]