Support better when blocks have been uploaded to block storage

[friedrichg]

Is your feature request related to a problem? Please describe. When recent blocks are uploaded directly to s3, queriers cannot immediately query them because of the -querier.query-store-after. Which is most of the times linked to -querier.query-ingesters-within for performance reasons. This leads to wrongful query results that last for querier.query-store-after.

Describe the solution you'd like A tenant that just uploaded blocks to s3 should have a specific query-store-after that matches the time of the upload or the default query-store-after, whichever is recent. Maybe a new type of tenant override can do it, but I am not sure.

Plus, we should also probably free the cache for that specific tenant in memcached.(or Redis). This could also just be an internal API, something like /cache/flush (like /ingester/flush, that accepts tenants)

Flushing the cache can only happen after 2 things have happened:

1. Compactors have updated the bucket index in s3 using -compactor.cleanup-interval (15m)
2. Store-gateway have refreshed the bucket index -blocks-storage.bucket-store.sync-interval (15m)

~So it's 30 minutes. But maybe we can also ignore cache for that tenant for the next 30 minutes.~ It can be more than 30 minutes, because compactor will take some time to download from s3 all the metas for the user. Maybe what is needed is an API path in compactor to trigger bucket-index update for the user. And a similar API path in store-gateway, queriers, rulers to trigger bucket index refresh.

Describe alternatives you've considered

• Current solution is restarting all caches and making querier.query-store-after=0 for a few hours for all tenants. That has performance implications for all tenants.

Additional context None

[friedrichg]

After long thought, I am thinking this flushing of cache is only going to be detrimental for the user. Cache should be ideally forever.

Also skipping the first deduplication of ingesters will make store-gateway see too many blocks in s3 which will increase store-gateway work.

So for me what makes sense now is to not upload to s3. What is appropriate is a cortex API that implements a bulk write path. The blocks should be queryable in a short time (less than 13 hours), probably in an ingester type component.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity in the past 60 days. It will be closed in 15 days if no further activity occurs. Thank you for your contributions.