Mtree出错（天远问题）

https://github.com/apache/iotdb/commit/4bb174842603441d501e779d9fc4ef7ebb77fe9e

在某个文件的 device 不全时，会读一个相邻 device 的数据，使合并结果多数据

我们的测试：无法及时找出改问题，原因是这个bug只有在查到 Mtree 进行递归查找时才能复现，这就需要很多 device，但我们的测试数据量较小

改进方案：在 compaction 测试前后设置了 max_degree_of_index_node

空间内合并丢数据

https://github.com/apache/iotdb/commit/f2e1dc925f7004f73d123684bf180f7d9ae17bd4

空间内合并过程中，每次会批量读每个文件 device 所包含的 1024 个序列进行合并，但是没有考虑到最后还剩下一些序列没被合并的情况，导致这些序列被遗漏，最后少数据

我们的测试：可以复现并找出该问题

合并与TTL产生冲突

https://github.com/apache/iotdb/commit/82da9773fec13d44483ad39fd26e2264458e0fe9

在原本的逻辑中，TTL 会判断需要删除的文件是否正在合并，如果正在合并就跳过不将其删除，但是这个遍历文件的过程和合并设置文件为正在合并状态的过程有冲突，导致合并报错。

现在修改为，TTL 不再判断需要删除的文件是否正在合并，直接删除文件，假如该文件正在合并，那么合并过程报错会自动退出，将合并出来的文件删除，即跳过了本次合并

跨空间合并丢数据

https://github.com/apache/iotdb/commit/c2fc008a0049ea8bf795b95e9454f003144379e0

在跨空间合并原本的逻辑中，只判断了顺序文件当前要合并的 device 是否有值，如果没数据就跳过合并这个 device，但是其实这时候有可能相应的乱序文件是有值的，只判断顺序文件就跳过，造成了合并出来的文件少数据

我们的测试：可以复现并找出该问题

空间内合并恢复出错

https://github.com/apache/iotdb/commit/87fb3d9b69b8b41e54ee6d2b50ad397aeb2eb1cd

在 tsfile list 原本的恢复逻辑中，会将已经封口的文件放到正常查询使用的 tsfile list 中，将需要合并恢复的文件放到 recover list 中，而合并恢复就会从 recover list 中取文件并恢复

但是当正好处在文件已经被合并完封口了，但是合并仍未结束（老文件未被删除）的情况，这个合并完的文件会被放到正常查询使用的 tsfile list 中，导致合并恢复取不到文件，最后恢复出错

我们的测试：可以复现并找出该问题

合并调度卡住

https://github.com/apache/iotdb/commit/e9aea37a0f8e00b5455a664a2e08ee58022a9f80

在一个线程池中的线程再向这个线程池提交任务，会导致线程无法再提交（卡住），因此修改了合并 pool 的使用

  • No labels