THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
用户升级手册
- 停止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,则需要升级进行文件移动
- 检查是否存在未关闭的v2 tsfile, 如果有,则退出系统
- 扫描各个存储组顺序与乱序的数据目录(仅针对在0扫描各个存储组的数据目录(仅针对在0.11的数据上第一次启动0.12),将所有文件移动到存储组的 upgrade 目录下(当做一个特殊分区号)
升级system.properties
- 使用iotdb_version的默认值设置到properties,与从旧文件中获得的信息一起写入到一个system.properties.tmp文件中。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
单独存到待升级的 upgradeSeqResourceList 和upgradeUnSeqResourceList中。
- StorageGroupProcessor
升级 TsFile
- 对于每个需要 在加载完resource后 upgrade service会对每个sg中,每个需要 upgrade 的文件提交异步升级任务
- 拿到resource读锁
- upgrade.txt 记录 (v2文件路径,1)
- 升级工具从前向后check v2 TsFile文件,将文件解到page级别
- 对于boolean、text、和Int32类型,将page解码到数据点级别,用v3版writer写成新的page data(原因:boolean需要生成sum的statistic,text和Int32中的int变成了varInt)
- 使用v3版ioWriter序列化新的chunk、pageheader结构,pagedata
- 关闭所有新生成的每一个新文件,并生成对应的新resource
- upgrade.txt 记录 (v2文件路径,2)
- 释放resource读锁
- 拿到resource写锁
- 删除旧tsfile和resource,将新生成的TsFile、resource和原本的mods文件(若有)移动到对应常规分区目录中
更新updateNewlyFlushedPartitionLatestFlushedTimeForEachDevice
- 删除旧tsfile和resource,将新生成的TsFile、resource和原本的mods文件(若有)移动到对应正常目录中,StorageGroupProcessor加载其resource到seqResource或unseqresource列表中如果此时StorageGroupProcessor中所有tsfile升级完成,将所有升级后的resource加载到tsFileManager中,并且更新partitionLatestFlushedTimeForEachDevice
- upgrade.txt 记录 (v2文件路径,3)
释放resource写锁
升级恢复
当升级未完成时,重启IoTDB时,需要根据upgrade.txt记录恢复升级
...