用户升级手册
- 停止0.11所有写入
- 开启cli,输入
flush
对所有未关闭TsFile进行封口 - 关闭cli,关闭0.11服务器端
- 配置0.12,把0.11 data目录迁移到0.12 相应位置,或在配置项里将0.12的data目录指向0.11的data目录位置
- 启动0.12,tsfile文件升级会在后台自动进行
升级目标
- 在线升级,即后台升级 TsFile 版本到 v3
- 0.12 可同时查询 TsFile v3 和 TsFile v2
升级流程
移动文件
升级第一次启动新版本需要移动文件
- 检查system.properties,如果iotdb_version=0.11.x,则需要升级进行文件移动
- 扫描各个存储组的数据目录(仅针对在0.11的数据上第一次启动0.12),将所有文件移动到存储组的 upgrade 目录下(当做一个特殊分区号)
升级system.properties
- 使用iotdb_version的默认值设置到properties,与从旧文件中获得的信息一起写入到一个system.properties.tmp文件中。
- 如果写入成功,删除旧的system.properties后将system.properties.tmp重命名为system.properties;
- 如果写入失败,会留下写入失败的system.properties.tmp和旧system.properties,此时我们需要重启iotdb重新进行升级
加载resource
StorageGroupProcessor 加载各个分区 resource,并且检查是否存在 upgrade 目录,将 upgrade 目录中的 TsFile 单独存到一份待升级的 resource 列表(顺序和乱序分开)
- StorageGroupProcessor
- SeqResourceList
- UnSeqResourceList
- upgradeSeqResourceList
- upgradeUnSeqResourceList
- StorageGroupProcessor
升级 TsFile
- 对于每个需要 upgrade 的文件提交异步升级任务
- 拿到resource读锁
- upgrade.txt 记录 (v2文件路径,1)
- 升级工具从前向后check v2 TsFile文件,将文件解到page级别
- 使用v3版ioWriter序列化新的chunk、pageheader结构,page data不用变,重新序列化即可
- 关闭所有新生成的每一个新文件,并生成对应的新resource
- upgrade.txt 记录 (v2文件路径,2)
- 释放resource读锁
- 拿到resource写锁
- 删除旧tsfile和resource,将新生成的TsFile、resource和原本的mods文件(若有)移动到对应正常目录中,StorageGroupProcessor加载其resource到seqResource或unseqresource列表中
- upgrade.txt 记录 (v2文件路径,3)
释放resource写锁
升级恢复
当升级未完成时,重启IoTDB时,需要根据upgrade.txt记录恢复升级
如果一个v2文件日志记录只有1:删除新生成的对应v3文件,之后该文件会重新升级
如果一个v2文件日志记录只有1,2:将新生成的TsFile、resource和原本的mods文件(若有)移动到对应正常目录中
恢复完成清空upgrade.txt