@Rocky Is there any method to clear data cache in shared-data cluster?

In StarRocks shared-data clusters, there is no single SQL command (like

CLEAR CACHE

) to purge the data cache. You can use one of the following two methods: Method 1: Manual Deletion (Recommended) This is the most thorough way to clear the cache. It requires a restart of the BE or CN nodes. 1. Stop the node (BE or CN). 2. Delete the cache directory located within your storage root path.

bash
   # Example: if storage_root_path = /data/disk1
   rm -rf /data/disk1/datacache/

3. Restart the node. The system will recreate the directory and start with a clean cache. Method 2: Dynamic Scaling (No Restart) You can force the system to evict all cached data by temporarily setting the cache quota to zero. This uses the

datacache_disk_size

parameter, which is mutable at runtime. 1. Set the cache size to 0 to trigger immediate eviction:

sql
   -- To clear cache on all nodes
   UPDATE be_configs SET VALUE = "0" WHERE NAME = "datacache_disk_size";

2. Restore the original cache size (e.g., 1TB or 80%):

sql
   UPDATE be_configs SET VALUE = "1T" WHERE NAME = "datacache_disk_size";

Notes: * Parameter persistency: Changes made via

UPDATE be_configs

are not persistent. If you restart the node, it will revert to the value defined in the

be.conf

file. * Shared-data specific config: While shared-data clusters use

starlet_star_cache_disk_size_percent

for initial sizing, that parameter is often immutable at runtime. Using the

datacache_disk_size

parameter as shown above is the standard workaround for dynamic clearing. * Impact: Clearing the cache will cause a temporary performance degradation for subsequent queries as data must be re-fetched from remote storage (S3/HDFS). References • administration/management/BE_configuration.md • data_source/data_cache.md

@Rocky If I use the dynamic scaling method, should I wait after changing the be_config or is cache flushed immediately?

When using the dynamic scaling method (setting

datacache_disk_size

to

0

), you should wait until the internal metrics confirm the cache has been evicted before resetting the quota. Here is what happens and how to verify it: 1. Eviction is Background-based When you set the quota to

0

, the system triggers an eviction process. However, StarRocks Data Cache (Block Cache) does not usually delete the physical files on disk immediately to avoid high I/O overhead. Instead, it invalidates the metadata and marks the space as "overwritable." 2. How to Verify (The "Wait" Period) Do not rely on OS commands like

du -h

, as they will likely still show the disk as full (since the files aren't physically deleted). Instead, use StarRocks internal metrics to see when the logical "Used" size drops: * Via SQL:

sql
    SELECT BE_ID, DISK_QUOTA_BYTES, DISK_USED_BYTES
    FROM information_schema.be_datacache_metrics;

Wait until

DISK_USED_BYTES

drops to

0

(or a very small value) for all nodes before you

UPDATE

the config back to your desired capacity. * Via SHOW BACKENDS: Check the

DataCacheMetrics

column in

SHOW BACKENDS

. It will display

DiskUsage: 0.00GB/...

when the flush is logically complete. 3. Important Note for Shared-Data Clusters In shared-data clusters, the cache size is determined by the greater of two values: *

datacache_disk_size

*

starlet_star_cache_disk_size_percent

If you have a value set for

starlet_star_cache_disk_size_percent

(e.g., 80%), you should ideally set both to

0

dynamically to ensure the cache is fully cleared, then restore them. Summary of Workflow 1. Set to 0:

UPDATE be_configs SET VALUE = "0" WHERE NAME = "datacache_disk_size";

2. Monitor: Run

SELECT * FROM information_schema.be_datacache_metrics;

every few seconds. 3. Reset: Once

DISK_USED_BYTES

is at or near

0

, set the config back to your original value. References • data_source/data_cache_observe.md • data_source/data_cache_troubleshooting.md • using_starrocks/caching/block_cache.md References • data_source/data_cache_troubleshooting.md • using_starrocks/caching/block_cache.md • data_source/data_cache.md • deployment/shared_data/feature-support-shared-data.md