<@U0A71G31CDV> Starrocks 3.5.10 - shared-data mod...
# questions-and-troubleshooting
a
@Rocky Starrocks 3.5.10 - shared-data mode. I have created an extra storage volume, created database on that storage volume, created an async materialized view on that storage volume, dropped that materialized view and dropped the database I've created. 12 hours have passed since, but, when I try to drop storage volume I am still getting an error saying Storage volume 'test_storage_volume' is referenced by dbs: [11211409]' where 11211409 does not correspond to any existing database. I've switched the storage volume to enabled=false, but, would like to know, how can I drop it completely.
r
Hi there! I'm Rocky. It sounds like you're running into a common situation with StarRocks' metadata management in shared-data mode. The reason you're seeing the error
Storage volume 'test_storage_volume' is referenced by dbs: [11211409]
even after dropping the database is that StarRocks does not physically delete the database metadata immediately. Instead, it moves it to an internal FE Metadata Recycle Bin (Trash). Why this happens By default, StarRocks retains dropped databases, tables, and partitions in this recycle bin for 24 hours (86,400 seconds). This allows you to use the
RECOVER
command if you accidentally delete something. Because the database metadata still exists in the trash with ID
11211409
, it still holds a "reference" to your storage volume, preventing the volume from being dropped. How to fix it Since you've only waited 12 hours, the metadata hasn't expired yet. To drop the storage volume immediately, you can temporarily lower the retention period to force a cleanup: 1. Lower the expiration timeout: Run this command to tell the Frontends (FE) to expire trash items older than 60 seconds:
Copy code
sql
    ADMIN SET FRONTEND CONFIG ("catalog_trash_expire_second" = "60");
2. Wait a few minutes: The FE has a background thread that runs periodically to clean up expired metadata. Wait about 5–10 minutes for this process to complete. 3. Drop the Storage Volume: Once the metadata for database
11211409
is physically purged, you should be able to drop the volume:
Copy code
sql
    DROP STORAGE VOLUME test_storage_volume;
4. Restore the default setting: It is highly recommended to set the timeout back to its default (1 day) to protect against accidental deletions in the future:
Copy code
sql
    ADMIN SET FRONTEND CONFIG ("catalog_trash_expire_second" = "86400");
Summary of configurations *
catalog_trash_expire_second
: Controls how long metadata (DB/Table/Partition info) stays in the FE trash. *
trash_file_expire_time_sec
: (BE side) Controls how long the actual physical data files stay in the storage before being deleted by the garbage collector. Let me know if this helps you clear out that volume! Referencesadministration/management/FE_configuration.mdfaq/operation_maintenance_faq.mdadministration/Data_recovery.mdfaq/shared_data_faq.mdknowledge/admin_and_operation/shared_data_garbage_cleanup.md
a
That worked, thank you @Rocky
r
You're very welcome! I'm glad I could help. If you have any more questions about StarRocks or run into any other issues, feel free to ask. Happy querying! 🚀