原有的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操作加兜底操作，一旦遇到失败，删除已经生成的目标文件，防止污染数据


  • No labels