-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Physically dropping table is slow sometime #8911
Labels
affects-7.5
This bug affects the 7.5.x(LTS) versions.
affects-8.1
This bug affects the 8.1.x(LTS) versions.
component/storage
severity/moderate
type/bug
The issue is confirmed as a bug.
Comments
JaySon-Huang
added
type/bug
The issue is confirmed as a bug.
severity/moderate
affects-7.5
This bug affects the 7.5.x(LTS) versions.
labels
Apr 8, 2024
12 tasks
Merged
12 tasks
12 tasks
This was referenced Apr 18, 2024
12 tasks
This was referenced Apr 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
affects-7.5
This bug affects the 7.5.x(LTS) versions.
affects-8.1
This bug affects the 8.1.x(LTS) versions.
component/storage
severity/moderate
type/bug
The issue is confirmed as a bug.
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
3. What did you see instead (Required)
In #8721, we introduce a rule that: "if the regions of a given table is not totally removed from TiFlash, skip physically dropping it". However, it does not set the
succeeded = false
, so after all it will update thelast_gc_safepoint
.When the whole cluster has few write commands, the gc_safepoint may not change. It make that the physically dropping only run after the gc_safepoint is changed again. Which will slow down the data disk reclaim.
4. What is your TiFlash version? (Required)
The text was updated successfully, but these errors were encountered: