为何UnsafeDestroyRange有一定概率删数据删不干净?

【 TiDB 使用环境】生产环境
【 TiDB 版本】未使用TiKV,只使用TiKV做KV存储, 使用TxnClient
【遇到的问题】

  1. UnsafeDestroyRange有一定概率删不掉数据,测试时发现有一定的机率(6%左右)被DestoryRange的数据居然能够被txn.Iter扫描出来,这是为何呢? 我简单翻阅过TiKV的代码,目前其实现是先调用Rocksdb::DeleteFilesInRange尝试快速释放空间,如果无效,则遍历逐个写入tombstone,但是不明白为何会出现数据残留。此外,逐个Delete能够换成Rocksdb::DeletRange写入RangeTombstone呢?因为感觉逐个遍历并Delete是不是开销有点大,GCWorker的Queue很容易被打满。

  2. 对一个非常大的Range(TB级别以上)做UnsafeDestroyRange会导致TiKV的IO被打满,时间持续数个小时以上, 这个有什么好的解决方案吗?

希望有官方同学答疑解惑,十分感谢!

之前看 tidb gc 代码时候也有为啥需要两次调用 UnsafeDestroyRange 的疑问:

1. 第一次是按照 safepoint 执行 UnsafeDestroyRange
2. 第二次是在 safepoint 24 小时之后

这个 rfc 有解释为什么第一次不能完全清理完成:

And why do we need to check it one more time after 24 hours? After deleting the range the first time, if coincidentally PD is trying to move a Region or something, some data may still appear in the range. So check it one more time after a proper time to greatly reduce the possibility.

IO 打满可能是由 compaction 导致:

After deleting all files in a very-large range, it may trigger RocksDB’s compaction (even it is not really needed) and even cause stalling.

好的 感谢您的答复~

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。