Planning to set

lake_autovacuum_grace_period_minutes=43200 # 30 days

for a shared-data cluster (v3.4.10) to support 30-day point in time recovery. Has anyone run with grace period this high long-term? Curious about real-world impact on query performance, compaction behavior, and any surprises we should watch for. Our business requirement is to have a point in time recovery backup of last 15 days and we plan to take cluster_snapshot once a day and move it to separate s3 bucket before it is over-written by the later snapshot. thanks

I'm sorry, but I don't have any context for what "above" refers to, as this is the beginning of our conversation. Could you please clarify what you would like recommendations on? For example: * Cluster Sizing: Hardware and instance type selection. * Table Design: Choosing between Duplicate, Aggregate, Unique, or Primary Key models. * Performance: Indexing (Bloom filter, Bitmap) or Partitioning/Bucketing strategies. * Data Ingestion: Using Stream Load, Routine Load, or Pipe. Once you provide some details, I can give you specific guidance!

@Rocky Planning to set

lake_autovacuum_grace_period_minutes

to 43200 (30 days) in production for a shared-data cluster (v3.4.10) to support 30-day PITR. Has anyone run with grace period this high long-term? Curious about real-world impact on query performance, compaction behavior, and any surprises we should watch for.

Setting

lake_autovacuum_grace_period_minutes

to 43200 (30 days) is a supported approach for enabling Point-In-Time Recovery (PITR) in StarRocks shared-data clusters. This setting prevents the "AutoVacuum" (Garbage Collection) process from deleting historical data segments and metadata that are no longer referenced by the latest version of a table. Here is a breakdown of the real-world impacts and things to watch for: 1. Query Performance * Latest Data: There is no negative impact on standard query performance for current data. Compaction continues to run normally, merging small files into larger ones to optimize read performance. The grace period only affects how long the old files are kept after they've been compacted away. * Long-Running Queries: This change is actually beneficial for stability. It prevents the common "meta does not exist" or "file not found" errors that occur when a query starts on an old version that gets vacuumed before the query finishes. 2. Storage Impact (The Primary Cost) * Storage Amplification: This is the most significant impact. Every load, delete, and compaction creates a new version. In a high-churn environment (frequent small loads), keeping 30 days of history can lead to 5x–10x (or more) storage growth compared to the

SHOW DATA

output, which only reflects the latest version. * Cost: Since data is on object storage (S3/GCS/Azure Blob), the cost is usually manageable, but you should monitor your bucket size closely after the first 30 days to establish a baseline. 3. Metadata and FE Impact * FE Memory: The FE must track these historical versions to support PITR. While StarRocks is designed to handle this, an extremely high frequency of transactions (e.g., thousands of loads per day across many partitions) combined with a 30-day retention can increase the FE metadata overhead. * Recovery Performance: PITR is performed using the

ADMIN REPAIR TABLE

statement. With 30 days of history, the initial scan to find the "healthy" version might take longer than with the default 30-minute grace period, though it remains a metadata-only operation and is generally fast (seconds to minutes). 4. Compaction Behavior * Compaction is not delayed. The system will continue to generate optimized versions of your data. The "vacuum" (GC) is the only part that waits for the 30-day grace period to expire before deleting the source files of those compactions. Important "Surprises" to Watch For * `lake_autovacuum_stale_partition_threshold`: By default (12 hours), if a partition has no updates, StarRocks stops performing AutoVacuum on it. If you have many historical partitions that are rarely updated, they might not be vacuumed even after the 30 days pass unless a new operation triggers it. * Object Storage API Costs: When the 30-day mark is hit, the first "vacuum" of that old data might involve a large number of

DELETE

requests to your object storage. Ensure your object storage provider's rate limits can handle the cleanup spikes. * PITR Limitations: This mechanism allows you to roll back a table's state to a previous version. It is not a "Time Travel" query feature (like

SELECT ... AS OF

); it is a disaster recovery tool. Recommendation: If your ingestion rate is high, monitor the difference between

SHOW DATA

(logical size) and your actual object storage bucket size. If the growth is unsustainable, consider a shorter grace period (e.g., 7 days) combined with a standard backup/restore strategy to a separate "cold" storage for the full 30-day requirement. References • administration/management/FE_configuration.md

@Kevin Cai do you have any suggestions about this strategy. thanks a lot

nope. grace period is not for point-in-time recovery. This 30days graceful period means all the historic versions (internal versions) won't be deleted, which introduces an heavy load to vacuum and also amplification to the storage usage.

thanks @Kevin Cai what do you suggest then. if we try to do versioning on bucket, we will still need to pay for storage and that is fine for us. but apart from storage cost, will increasing the

lake_autovacuum_grace_period_minutes

to 30 days cause issue on query performance?