With compaction or retention logic we have one "writer" that creates new blocks (compaction) and deletes blocks that were source of it.
The problem with our readers (store) is that syncing is periodically every X seconds. So it might happen that we query store during time of compactor remove the block, but store did not sync yet. There is no watch logic for Bucket API.
The simplest solution is to defer deletion in some time in future to address potential eventual consistency of store Gateway internal state (and potentially bucket itself)
Acceptance criteria:
This unfortunately requires the heavy modification of compactor Plan logic to understand the edge cases like:
This has to be done and is planned to be done EOY
This will be fixed by: https://github.com/thanos-io/thanos/issues/1528 help wanted (:
Why we doesn't trigger a resync with remote in reader component (thanos store), if a block (deleted by compactor) isn't found?
@Reamer
We can, but still sync takes time, so ideally we can do it in a smarter way as defined by https://github.com/thanos-io/thanos/issues/1528
Also trigger will involve coordination which we don't want.
This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.
@khyatisoneji is on it (:
This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.
We are super close to merge the fix! But not yet fixed.
This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.
Most helpful comment
Fixed by https://github.com/thanos-io/thanos/pull/2136