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

jiyf · 2022 年9 月 7 日 11:32

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

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

github.com

tikv/rfcs/blob/master/text/0002-unsafe-destroy-range.md

# Unsafe Destroy Range

## Summary

Support RPC `UnsafeDestroyRange`. This call is on the whole TiKV rather than a
certain Region. When it is invoked, TiKV will use `delete_files_in_range` to
quickly free a large amount of space, and then scan and delete all remaining
keys in the range. Raft layer will be bypassed, and the range can cover
multiple Regions. The invoker should promise that after invoking
`UnsafeDestroyRange`, the range will **never** be accessed again. That is to
say, the range is permanently scrapped.

This interface is only designed for TiDB. It's used to clean up data after
dropping/truncating a huge table/index.

## Motivation

Currently, when TiDB drops/truncates a table/index, after GC lifetime it will
invoke `DeleteRange` on all affected Regions respectively. Though TiKV will
call `delete_files_in_range` to quickly free up the space for each Region, the

该文件已被截断。显示原文

这个 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.