-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Logs deletion fixes #4625
Logs deletion fixes #4625
Conversation
pkg/storage/stores/shipper/compactor/deletion/delete_requests_manager.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I'd love to have a comment to explain why just with the request it's not enough to figure if a table should be inspected or not.
… could span multiple tables
Co-authored-by: Cyril Tovena <cyril.tovena@gmail.com>
82e7ae5
to
ee3819e
Compare
Thanks for the review folks! I have taken care of the suggestions. |
t.markerMetrics.tableProcessedTotal.WithLabelValues(tableName, tableActionNone).Inc() | ||
return empty, markerWriter.Count(), nil | ||
return empty, modified, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiny nit: but I think it makes it slightly easier to read to hard-code this value to false
, as it doesn't require the reader to invert the condition (which is already an inversion) that got them here,
} | ||
t.markerMetrics.tableProcessedTotal.WithLabelValues(tableName, tableActionModified).Inc() | ||
return empty, markerWriter.Count(), nil | ||
return empty, modified, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here with hard-coding to true
What this PR does / why we need it:
It includes the following two changes:
We check for whether the table would have chunks requested for deletion based on the delete request interval and the interval for which the table is expected to hold data or get queries, calculated using the table number. The problem here though is a chunk could overlap multiple tables so if a delete request is deleting the chunk for just one of the days, the index entry would stay untouched for the days for which the chunk has not been requested for deletion. To avoid this problem I am making compactor to go through all the index tables since it is hard to know how many tables a chunk could overlap. I had noticed chunks overlapping as long as 7 tables so it is safe to not skip any tables for now, until I can find a way to make this optimization work for delete requests too.
We upload the modified index from a table only when a chunk indexed in it has been marked for deletion. With some conditions, we sometimes just drop the index entry without marking chunk for deletion. This PR adds a check for it and uploads the index when it is modified even without marking any chunks for deletion.
Checklist
CHANGELOG.md
about the changes.