原有的merge:
1、顺序文件名会变,数量不变
2、乱序文件会被合并到已有的顺序文件中
现有的分布式的catchup:
1、raft日志删除时机:
大小到达某阈值(此时数据不一定已写入tsfile中,当raft日志删除后,需要wal去恢复,测试不能关wal)
2、raft的snapshot时机和catchup流程
leader发现某个follower缺少数据且这些数据已不在raft日志中,会触发snapshot:
a、等待leader的apply id>=commit id,然后flush
b、把当前系统的timeseries schema做snapshot放在内存中
c、把datagroup的所需的tsfile做硬链接,确保这些文件无法被物理删除(?拿完顺序之后,乱序文件被合并完了=>变成先拿乱序再拿顺序)
所需是指:找到文件中plan index属于follower缺失的那部分
d、把timeseries schema、leader现在的commit id和文件列表发给follower
e、follower注册timeseries schema并下载文件列表内文件
f、follower更新自己的commit id
g、leader三天后自动清除本地的硬链接
现有的merge:
1、顺序文件可能会被删除,形成新的顺序文件
2、乱序文件可能自己做层级合并
冲突性分析:
1、删除顺序文件是否会有冲突(?文件列表操作加个锁)
merge操作对文件列表的维护分为两步骤:
将新生成的文件加入列表、将旧的文件移除列表,这两个操作通过锁保证原子性。
若snapshot不对文件列表加锁时,当snapshot发生在第一步和第二步之间,则会将新旧数据均列入snapshot,导致数据重复,但不丢失数据。
snapshot加锁可避免上述现象,但是不清楚snapshot对文件列表的操作是否耗时过长。
此外,snapshot不加锁还有并发冲突问题,后续有两种修改方案(加锁或屏蔽异常,倾向于加锁)
2、形成新的顺序文件
新的顺序文件形成后,plan index实际是不变的,而拉snapshot其实只与plan index相关,所以不会有冲突。
3、snapshot拉到本地后与某些文件完全重复会直接删除本地文件
merge操作如果遇到一个不存在的文件,会报错,但是现有的merge流程只catch了此类错误,没有处理
只需要对所有merge操作加兜底操作,一旦遇到失败,删除已经生成的目标文件,防止污染数据