@Rocky how to do Self-Service Patch Upgrades/version upgrades to execute with zero-downtime?

To execute a zero-downtime upgrade in StarRocks, you must perform a rolling upgrade. This process involves upgrading nodes one by one while the rest of the cluster remains operational. 1. Prerequisites for Zero-Downtime * High Availability (HA): Your cluster must have multiple FE nodes (Follower/Observer) and multiple BE nodes. If you only have one FE, service will be interrupted when that node restarts. * Sequential Order: You must upgrade BEs and CNs first, and then FEs. * Version Path: * Patch upgrades (e.g., v3.1.2 to v3.1.5) can be done directly. * Minor/Major upgrades (e.g., v2.5 to v3.0) should be done consecutively (v2.5 -> v3.0 -> v3.1). 2. Pre-Upgrade Preparation Before starting, disable tablet balancing and cloning to prevent the cluster from attempting to redistribute data while nodes are being restarted:

sql
-- Disable tablet balancing and cloning
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_scheduling_tablets" = "0");
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_balancing_tablets" = "0");
ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");
ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");

3. Upgrade Procedure (Rolling) Step 1: Upgrade BEs and CNs (One by One) For each BE/CN node: 1. Stop the node: Use

./bin/stop_be.sh

(or

./bin/stop_cn.sh --graceful

). 2. Replace binaries: Replace the

bin

and

lib

directories with the new version's files. 3. Start the node: Use

./bin/start_be.sh --daemon

. 4. Verify: Check the node status in StarRocks (

SHOW BACKENDS;

) and ensure it is

Alive

. Wait for the node to be fully functional before moving to the next. Step 2: Upgrade FEs (One by One) You must upgrade Follower FEs first, and the Leader FE last. 1. Stop the node: Use

./bin/stop_fe.sh

. 2. Replace binaries: Replace the

bin

,

lib

, and

spark-dpp

directories. 3. Start the node: Use

./bin/start_fe.sh --daemon

. 4. Verify: Check

SHOW FRONTENDS;

to ensure the node is

Alive

and has joined the cluster. 5. Finalize: Once all Followers are upgraded, stop the Leader FE. A new Leader will be elected from the already-upgraded Followers. Then upgrade and restart the old Leader. 4. Post-Upgrade Tasks Once all nodes are upgraded and showing as

Alive

, re-enable tablet balancing:

sql
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_scheduling_tablets" = "10000");
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_balancing_tablets" = "500");
ADMIN SET FRONTEND CONFIG ("disable_balance" = "false");
ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "false");

5. Automated "Self-Service" via Kubernetes If you are using the StarRocks Operator on Kubernetes, you can achieve a zero-downtime upgrade by simply updating the image version in your StarRocksCluster CRD. The Operator automatically handles the rolling restart logic (BEs first, then FEs) and ensures HA is maintained during the process.

bash
kubectl patch starrockscluster <cluster_name> --type='merge' -p '{"spec":{"starRocksBeSpec":{"image":"starrocks/be-ubuntu:3.1.5"}}}'

References • deployment/sr_operator.md • deployment/upgrade.md

@Rocky does starrocks supports warehouse in shared nothing architecture?

No, StarRocks does not support the "Multi-Warehouse" (Compute Group) feature in a shared-nothing architecture. The specific "Warehouse" functionality—which allows you to create independent, elastic compute clusters that access the same data—is exclusive to the shared-data (compute-storage separation) architecture. Key Differences in how StarRocks handles this: 1. Shared-Nothing Architecture (Traditional) * Coupled Resources: Data is physically stored on the local disks of specific BE (Backend) nodes. Computation for that data must happen on those specific nodes. * No Multi-Warehouse: You cannot spin up a second, independent "warehouse" of BEs to query the same internal data because that data only lives on the first set of BEs. * Isolation Method: In this architecture, you achieve resource isolation using Resource Groups (Workload Management). You can limit CPU and Memory for different users or workloads within the same cluster of BEs. 2. Shared-Data Architecture (Compute-Storage Separation) * Decoupled Resources: Data is stored in central object storage (S3, GCS, HDFS, etc.). * Multi-Warehouse Support: You can create multiple Compute Groups (Warehouses) consisting of stateless CN (Compute Nodes). * Elasticity: Since the data is shared in central storage, you can scale these warehouses independently. For example, you can have one warehouse for data loading and another for BI queries, ensuring they don't compete for compute resources. Summary Table Feature | Shared-Nothing | Shared-Data Node Types | FE + BE | FE + CN Storage | Local Disk (Coupled) | Object Storage (Disaggregated) Warehouse Feature | Not Supported | Supported (as Compute Groups) Primary Isolation | Resource Groups (CPU/Mem limits) | Independent Warehouses If you need true multi-warehouse isolation, you should deploy StarRocks in shared-data mode (available starting from v3.0). _Ref: introduction/Architecture.md, deployment/shared_data/_ References • introduction/Architecture.md • table_design/table_design.md

@Rocky how to isolate resources in shared nothing between query serving, update tasks and MVs? Resource Groups

In a shared-nothing architecture, you can isolate resources using Workload Management (Resource Groups). Since data is tied to BE nodes, Resource Groups manage the CPU, memory, and concurrency on each BE to ensure one workload (like an MV refresh) doesn't starve another (like interactive queries). Here is how to set up isolation for your specific workloads: 1. Isolate Materialized Views (MVs) StarRocks provides a system-defined group (

default_mv_wg

), but it is best practice to create a dedicated group for MVs. * Create Group: Limit CPU weight and memory to ensure MVs run in the "background."

sql
    CREATE RESOURCE GROUP rg_mv
    WITH (
        "cpu_weight" = "10",        -- Soft limit: gets 10% of CPU if contention occurs
        "mem_limit" = "0.3",         -- Can use up to 30% of BE memory
        "concurrency_limit" = "5"    -- Limit simultaneous refresh tasks
    );

* Assign to MV: You can bind the group directly to the MV definition.

sql
    ALTER MATERIALIZED VIEW my_mv SET ("resource_group" = "rg_mv");

2. Isolate Query Serving You typically want queries to have high priority and low latency. Use Classifiers to automatically route user queries to this group. * Create Group:

sql
    CREATE RESOURCE GROUP rg_queries
    TO (user='reporting_user', role='analytics') -- Classify by user/role
    WITH (
        "cpu_weight" = "70",
        "mem_limit" = "0.5",
        "type" = "short_query" -- Optimization for sub-second queries
    );

3. Isolate Update Tasks (Data Loading) Resource Group support for updates depends on the loading method: * INSERT INTO / INSERT OVERWRITE: Supported via classifiers (since v2.5). * Broker Load: Supported via classifiers (since v3.1). * Stream Load / Routine Load: Not yet supported by Resource Groups (as of v3.3). These tasks currently use a fixed portion of BE resources not managed by the Workload Manager. * Configuration for INSERT-based updates:

sql
    CREATE RESOURCE GROUP rg_updates
    TO (query_type IN ('insert')) -- Classify all INSERT statements
    WITH (
        "cpu_weight" = "20",
        "mem_limit" = "0.2"
    );

Summary of Resource Controls Resource | Soft Limit (

cpu_weight

) | Hard Limit (

cpu_core_limit

) CPU | Allows a group to exceed its limit if the BE is idle. | Strictly caps CPU (v3.3.5+). Recommended for strict isolation. Memory |

mem_limit

sets a percentage of the BE's total queryable memory. | Queries exceeding this will be killed or queued. Concurrency |

concurrency_limit

prevents the FE from scheduling too many parallel tasks. | Useful for preventing MV refreshes from overwhelming the system. Key Tip: CPU Hard Limits If you are on v3.3.5 or later, you can use

cpu_core_limit

instead of

cpu_weight

. This provides hard isolation, meaning even if the cluster is idle, the update/MV task will never exceed the specified number of cores, ensuring 100% predictable performance for your query serving group.

sql
-- Example of a hard limit
ALTER RESOURCE GROUP rg_mv WITH ("cpu_core_limit" = "4");

-- Verify status SELECT * FROM information_schema.resource_groups; ``` ## References - [administration/management/resource_management/resource_group.md](https://docs.starrocks.io/docs/administration/management/resource_management/resource_group) - [best_practices/audit_log_resource_group.md](https://docs.starrocks.io/docs/best_practices/audit_log_resource_group) - [faq/resource_isolation_faq.md](https://docs.starrocks.io/docs/faq/resource_isolation_faq) ## References - [faq/resource_isolation_faq.md](https://docs.starrocks.io/docs/faq/resource_isolation_faq) - [best_practices/audit_log_resource_group.md](https://docs.starrocks.io/docs/best_practices/audit_log_resource_group) - [administration/management/resource_management/resource_group.md](https://docs.starrocks.io/docs/administration/management/resource_management/resource_group)