@Rocky can I add compute nodes to a shared nothing cluster

Technically, you can add Compute Nodes (CNs) to a shared-nothing cluster, but it is not recommended according to the StarRocks documentation. Key Considerations: • Official Recommendation: The StarRocks manual deployment guide states that adding CN nodes to shared-nothing clusters may lead to "unknown behaviors" and is generally discouraged. • Architectural Fit: • Shared-nothing clusters are designed to use Backend (BE) nodes, which handle both data storage and computation. To scale resources in this mode, you should add more BE nodes. • Shared-data (Compute-Storage Separation) clusters are the intended environment for Compute Nodes (CNs). In this mode, CNs are stateless and data is stored in remote object storage (like S3 or HDFS). • Functionality: While CNs are stateless and can execute query plans, they cannot host data replicas. In a shared-nothing setup, they would only be able to participate in the "compute" part of queries (such as processing data sent from BEs or querying external tables), but this hybrid configuration is not a standard or well-tested deployment pattern. Recommendation: • If you need to scale a shared-nothing cluster, add more BE nodes using:

sql
  ALTER SYSTEM ADD BACKEND "host:port";

• If you require the ability to scale compute independently and elastically without data rebalancing, you should consider deploying a shared-data cluster instead, where CNs are the primary compute unit. References • deployment/shared_data/hdfs.md • introduction/Architecture.md • deployment/shared_data/s3.md • quick_start/shared-data.md • table_design/table_design.md • deployment/shared_data/minio.md

@Rocky I want to add compute for routine load, but not for tablet storage, because I want it to be temporary

While you can technically add Compute Nodes (CNs) to a shared-nothing cluster, it is strongly discouraged and likely won't achieve your goal of temporary compute for Routine Load without storage overhead. Here is the breakdown of why this approach is problematic and what the alternatives are: 1. Architectural Restriction The StarRocks documentation explicitly states that adding CN nodes to a shared-nothing (BE-based) cluster is not recommended and may lead to "unknown behaviors." CNs are designed for the shared-data architecture (using object storage like S3/HDFS). 2. Routine Load Behavior in Shared-Nothing In a shared-nothing cluster, Routine Load tasks are handled by BE nodes. The parallelism of a Routine Load job is determined by the formula:

min(alive_be_number, partition_number, desired_concurrent_number, max_routine_load_task_concurrent_num)

• Task Assignment: In shared-nothing mode, the FE typically schedules Routine Load tasks to BE nodes because they are the "owners" of the data tablets. • Data Flow: Even if a CN were to act as a "coordinator" (consuming Kafka data and parsing it), it would still have to push that data over the network to the specific BEs that host the target tablets. In a shared-nothing setup, the storage bottleneck (writing to disk) remains on the BEs. 3. The "Storage" Problem If you add a standard BE node to increase compute power, the FE will immediately see it as a new storage resource and start rebalancing tablets to it. This defeats your "temporary" requirement, as removing that node later would trigger another massive data rebalance. Recommended Solutions Option A: Migration to Shared-Data (Recommended for Elasticity) If your workload requires scaling compute independently of storage (e.g., heavy loading periods), the shared-data architecture is designed exactly for this. • In this mode, you use CNs instead of BEs. • CNs are stateless; you can add 10 CNs to handle a massive Kafka spike and terminate them an hour later with zero data rebalancing. Option B: Resource Groups (Workgroups) If you must stay on shared-nothing, you can use Workgroups to isolate the CPU/Memory used by Routine Load on your existing BEs. This doesn't add "new" nodes, but it prevents Routine Load from "stealing" compute from your high-priority queries during peaks. Option C: Scale BEs and "Decommission" If you add BEs temporarily, you must use the

DECOMMISSION

command to remove them later. This ensures data is moved back to the original nodes before the temporary nodes are shut down. However, this involves significant IO and is not "instant" like scaling CNs. Summary Adding CNs to a shared-nothing cluster to "offload" Routine Load is not a supported or functional pattern. To get true elastic compute without storage rebalancing, you should plan a migration to the StarRocks shared-data architecture. References • deployment/deploy_manually.md • loading/loading_introduction/loading_concepts.md • loading/RoutineLoad.md • introduction/Architecture.md • faq/loading/Routine_load_faq.md • sql-reference/sql-statements/loading_unloading/routine_load/CREATE_ROUTINE_LOAD.md References • loading/loading_introduction/loading_concepts.md • quick_start/routine-load.md • deployment/deploy_manually.md