Hi! Forgive me if this has been asked before - We are trying to deploy StarRocks in shared-data mode via the official operator into a k8s cluster (3 CN nodes, 3 FE nodes, FE Proxy) w/ (local) S3-type storage as persistent storage. We need to be able to restore the SR cluster state (data and metadata) from S3 even if the cluster deployment itself is removed/uninstalled/fails, etc. The major hurdle is this: the SR cluster UUID is randomly generated at deploy time and the S3 storage path is based on the UUID. When we do a full teardown and redeploy, the SR cluster uses a new UUID and cannot find its prior data because it has no record of the prior UUID. My questions are: 1) Is it possible to force a particular UUID at deploy time to ensure that a given SR deployment has a predictable name/id? 2) If so, is this option available in the operator? 2) Is this the correct way to manage persistent database state in cases of hardware failure? Thanks in advance!

@Nick Weiler I'm afraid that UUID is auto-generated and not configurable. There's no way to do this currently. The best way to manage persistent database state is the Cluster Snapshot feature (introduced in 3.4.2, improved in 3.5.x). It snapshots the metadata (which is all that is in the cluster itself, in shared-data clusters) to the object storage.