Compact tenant TSDBs after 3h inactivity #5909
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Receiver tenant retention mechanism has an edge case when a tenant TSDB gets evicted and uploaded to S3. Since there is a delay between uploads to S3 and downloads in Store Gateways, if a user executes a query between the upload and download time, they may not see the latest head block from the evicted tenant. As a result, this commit decouples head compaction from tenant eviction. Head compaction, as in Prometheus, will happen if there are no new appends after 1.5x max-block-size. This will also cause the compacted block to be uploaded to S3 by the shipper. Eviction will then kick in which will cause the tenant TSDB to be deleted. By this time, the latest head block would have been picked up by store-gateway and would be available during query execution. Signed-off-by: Filip Petkovski <[email protected]>
fpetkovski
force-pushed
the
compact-tenants
branch
from
c4523c2 to
1a033af
Compare
ngraham20
pushed a commit
to ngraham20/thanos
that referenced
this pull request
May 18, 2023
The Receiver tenant retention mechanism has an edge case when a tenant TSDB gets evicted and uploaded to S3. Since there is a delay between uploads to S3 and downloads in Store Gateways, if a user executes a query between the upload and download time, they may not see the latest head block from the evicted tenant. As a result, this commit decouples head compaction from tenant eviction. Head compaction, as in Prometheus, will happen if there are no new appends after 1.5x max-block-size. This will also cause the compacted block to be uploaded to S3 by the shipper. Eviction will then kick in which will cause the tenant TSDB to be deleted. By this time, the latest head block would have been picked up by store-gateway and would be available during query execution. Signed-off-by: Filip Petkovski <[email protected]> Signed-off-by: Filip Petkovski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Receiver tenant retention mechanism has an edge case when a tenant TSDB gets evicted and uploaded to S3. Since there is a delay between uploads to S3 and downloads in Store Gateways, if a user executes a query between the upload and download time, they may not see the latest head block from the evicted tenant.
As a result, this commit decouples head compaction from tenant eviction. Head compaction, as in Prometheus, will happen if there are no new appends after 1.5x max-block-size. This will also cause the compacted block to be uploaded to S3 by the shipper. Eviction will then kick in after tsdb retention time, which will cause the tenant TSDB to be deleted.
By this time, the latest head block would have been picked up by store-gateway and would be available during query execution.
Signed-off-by: Filip Petkovski [email protected]
Changes
Verification
Unit tests and manual verification.