本文基于一次真实的 IoTDB 1.3.3 单副本 3C3D 集群搬迁整理出 9 个可复用脚本、关键参数含义以及 load 过程中最容易踩的 5 个坑。适合需要在不停业务写入的前提下把 TsFile 从 A 集群搬到 B 集群的运维同学参考。一、为什么用 TsFile 搬迁IoTDB 的TsFile 是列式时序存储文件搬迁 TsFile 相当于搬运数据块相比 SQL 导出再写入- 无需重新解析和序列化吞吐更高- 保留原始编码、压缩、索引结构- 通过load命令即可把历史数据注入新集群- 适合 TB 级、百亿点时序数据的大批量迁移二、整体流程三、环境假设- 源集群、HDD 临时集群、新 SSD 目标集群均为IoTDB 1.3.3- 均为3 个 ConfigNode 3 个 DataNode3C3D- 采用单副本data_replication_factor1、schema_replication_factor1- 脚本执行机已对 6 台节点配置 SSH 免密登录- 目标集群已创建与原集群一致的 database四、9 步脚本详解以下脚本默认放在同一目录先修改00_env.conf中的 IP、路径、密码再按顺序执行。Step 01 flush把 MemTable 落盘成完整 TsFile#!/bin/bash set -e source ./00_env.conf flush_node() { local node_ip$1 local node_name$2 echo 正在对 ${node_name}(${node_ip}) 执行 flush... ssh ${SSH_USER}${node_ip} cd ${SSD_IOTDB_HOME} ./sbin/start-cli.sh -h ${node_ip} -p ${IOTDB_CLI_PORT} \ -u ${IOTDB_CLI_USER} -pw ${IOTDB_CLI_PASS} -e flush; } flush_node ${SSD_NODE1_IP} SSD-Node1 flush_node ${SSD_NODE2_IP} SSD-Node2 flush_node ${SSD_NODE3_IP} SSD-Node3要点flush 是节点级操作3 个 DataNode 都要执行。flush 后建议等待 2-3 分钟确保后台文件写入完成。Step 02 打包保留目录结构和元数据ssh ${SSH_USER}${node_ip} cd ${SSD_DATA_DIR} # 序列化和非序列化数据 tar czf ${LOCAL_TMP_DIR}/${pkg_name}_data.tar.gz sequence/ unsequence/ # .resource 和 .mods 必须一起打包 find ${SSD_DATA_DIR} -type f \( -name *.resource -o -name *.mods \) | \ tar czf ${LOCAL_TMP_DIR}/${pkg_name}_meta.tar.gz -T - 注意不能只拷贝.tsfile。.resource是索引文件.mods记录删除标记漏带会导致 load 重建索引或丢失删除操作。Step 03 传输保持 node1→node1 的对应关系单副本集群的数据分片分散在 3 个节点搬迁时要保持分片对应不能混装。脚本用 scp 把每个 SSD 节点的包传到 HDD 集群对应节点。Step 04 load把 TsFile 注入 HDD 临时集群#方案1 登录到控制台使用命令load ./sbin/start-cli.sh -h ${node_ip} -p ${IOTDB_CLI_PORT} \ -u ${IOTDB_CLI_USER} -pw ${IOTDB_CLI_PASS} -e load ${HDD_BACKUP_DIR}/tsfile_data/sequence/ with (onSuccessnone, verifytrue); #方案2 使用IoTDB自带的tools脚本工具推荐 #序列化数据 nohup ./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_erros/load_se.log #非序列化数据nohup ./load-tsfile.sh -h 127.0.0.1 -p 6667 -u root -pw root -s /data/backup_from_ssd/tsfile_data/unsequence/ -tn 6 -os none -of none /data/load_erros/load_unse.log参数解释onSuccessnone表示加载成功后不删除源文件便于重复验证verifytrue开启文件校验提前发现损坏。具体案例中我使用了方案2有日志输出便于分析。Step 05 验证四件套检查# 1. database 列表 show databases; # 2. 时序数量 show timeseries root.**; # 3. 总数据点数 select count(*) from root.**; # 4. TsFile 文件数量 磁盘占用 find ${HDD_DATA_DIR} -name *.tsfile | wc -l du -sh ${HDD_DATA_DIR}参数解释迁移前一定要预留充足的磁盘空间。Step 06-09 回迁HDD → 新 SSD逻辑与阶段 1 对称对 HDD 集群执行 flush 打包传回新 SSD 集群对应节点再 load 并做最终验证。这里不再重复贴代码可直接复用阶段 1 的脚本模式。五、脚本清单脚本作用执行时机00_env.conf环境变量配置IP、路径、密码必须先改01_flush_ssd.shSSD 集群 flush迁移开始前02_backup_ssd.shSSD 各节点打包 TsFileflush 后03_transfer_to_hdd.sh传输到 HDD 对应节点打包后04_load_hdd.shHDD 集群 load 数据传输完成后05_verify.sh验证集群数据load 后 / 回迁后06_backup_hdd.shHDD 集群 flush 打包回迁前07_transfer_to_new_ssd.sh传回新 SSDHDD 打包后08_load_new_ssd.sh新 SSD load 数据传输完成后09_verify_new_ssd.sh最终验证全部完成后脚本说明实际操作的脚本内容可参看我另外一篇文章《10TB、20天、公有云接力一次 IoTDB 数据迁移的真实复盘》六、关键参数配置参数推荐值说明data_replication_factor1单副本减少数据冗余和搬迁量schema_replication_factor1与 data_replication_factor 保持一致onSuccessnone加载成功不删除源文件便于重试verifytrue加载前校验 TsFile 完整性enable_cross_space_compactionfalseHDD 上建议关闭避免随机 I/O 拖垮写入compaction_schedule_interval_in_ms60000降低 HDD 上 compaction 频率实操中确实提高了频率为了让快速检测。不然按86400000 ms 需要等待一天。七、踩坑清单现象原因解决load 报 file not found路径不是绝对路径始终使用绝对路径传参load 后 count(*) 变少漏带.mods文件打包时把.resource和.mods一起带上HDD 上 load 极慢触发了 cross space compaction关闭 cross space compaction调大 schedule interval新 SSD load 失败database 未创建load 前先CREATE DATABASE同一 TsFile 被重复加载分片对应关系混乱严格保持 node1→node1、node2→node2、node3→node3八、环境配置模板# ---- SSD 原集群3个DataNode---- SSD_NODE1_IP192.168.1.11 SSD_NODE2_IP192.168.1.12 SSD_NODE3_IP192.168.1.13 SSD_IOTDB_HOME/opt/iotdb-1.3.3 SSD_DATA_DIR/opt/iotdb-1.3.3/data/datanode/data # ---- HDD 临时集群 ---- HDD_NODE1_IP192.168.2.21 HDD_NODE2_IP192.168.2.22 HDD_NODE3_IP192.168.2.23 HDD_BACKUP_DIR/data/backup_from_ssd # ---- 新 SSD 目标集群 ---- NEW_SSD_NODE1_IP192.168.1.31 NEW_SSD_NODE2_IP192.168.1.32 NEW_SSD_NODE3_IP192.168.1.33 NEW_SSD_BACKUP_DIR/data/backup_from_hdd # ---- IoTDB 连接信息 ---- IOTDB_CLI_USERroot IOTDB_CLI_PASSroot IOTDB_CLI_PORT6667 SSH_USERroot九、什么场景适合这套方案- 源和目标集群版本一致且可以短期停机做 flush- 数据量达到 TB 级SQL 导出/写入不可接受- 有中间临时集群或单机大磁盘作为跳板- 需要保留历史数据的时间序列结构、编码和压缩方式不适合的场景源和目标版本不一致需要实时同步、零停机的在线迁移对多副本强一致有要求的环境。
)
)