@Rocky I am getting

Error 1064 (HY000): Build Exec OlapScanNode fail, scan info is invalid

trying to list (Select) a native table in a Shared-Data architecture. •

SHOW COMPUTE NODES;

only shows my 6 CNs in a "Normal" status

The error

Error 1064 (HY000): Build Exec OlapScanNode fail, scan info is invalid

usually indicates that the StarRocks Frontend (FE) planner is unable to find any available or healthy Compute Nodes (CN) to handle the scan task for that specific table. Even though

SHOW COMPUTE NODES

shows them as "Normal," there are several architecture-specific reasons why this might happen in a Shared-Data (Lake) environment: 1. Warehouse/Cluster Assignment In Shared-Data mode, queries are executed on a specific Warehouse. If your session is not pointing to the warehouse where your CNs are located, the planner will fail to find nodes. * Check your current warehouse:

sql
    SELECT current_warehouse();

* Check warehouse status:

sql
    SHOW WAREHOUSES;

* Action: If the current warehouse has 0 nodes or is different from where your 6 CNs are, switch to the correct one:

sql
    SET warehouse = 'your_warehouse_name';

2. Lack of Available CNs for the Scan Range The "scan info is invalid" message often implies the FE could not generate a valid scan range because no CNs were found in the "alive" or "available" list during the planning phase. * Heartbeat vs. Connectivity: A CN might show "Normal" in

SHOW COMPUTE NODES

(meaning the heartbeat is okay), but the FE might still fail to communicate with it for plan distribution. * Action: Check the FE leader's log (

fe.warn

or

fe.log

) at the time of the error. It usually prints a more detailed message like

Compute node not found

or

nodeId: -1

, which confirms the planner couldn't find a destination for the tablets. 3. Metadata Inconsistency (Primary Key Tables) If this is a Primary Key table and you have recently performed heavy

STREAM LOAD

,

INSERT

, or

TRUNCATE

operations, the FE metadata cache might be out of sync. * Symptoms: Queries with

LIMIT

work, but

SELECT _

or

COUNT(_)

fail. * Action: Try restarting the Leader FE node to force a metadata refresh. 4. Tablet/Shard Issues In Shared-Data, tablets are managed as shards in the object storage. If the FE cannot retrieve the tablet metadata or if the tablets are in an abnormal state: * Check Tablet Status:

sql
    SHOW TABLET FROM <table_name>;
    -- Pick a TabletId from the results
    SHOW PROC '/statistic/<TabletId>';

* Corrupted Metadata: If you see "no queryable replica found," it might mean the cloud metadata service (managed by the FE) cannot find the shard's record. Troubleshooting Checklist 1. Verify Warehouse: Ensure

SET warehouse = '...'

is correctly set. 2. Check FE Logs: Look for the specific error in

fe.log

. It often provides the

nodeId

it was trying to reach. 3. Validate Table Metadata: Run

DESC <table_name>

and

SHOW CREATE TABLE <table_name>

to ensure the table structure is intact. 4. Object Storage Connectivity: Ensure the CNs can actually reach the S3/MinIO/Azure bucket endpoint. If they can't fetch the tablet metadata from storage, the scan will fail. References • faq/shared_data_faq.md • quick_start/shared-data.md • deployment/shared_data/azure.md

@Rocky The WarehouseName is

default_warehouse

for all my nodes with

SHOW COMPUTE NODES;

. However,

SHOW WAREHOUSES;

shows

NodeCount

to

0

The fact that

SHOW COMPUTE NODES

lists your 6 nodes but

SHOW WAREHOUSES

reports a

NodeCount

of

0

is the root cause of the

Build Exec OlapScanNode fail

error. In StarRocks Shared-Data (lake) mode, especially starting with version 3.0, the query engine needs nodes to be explicitly associated with a Warehouse to execute scans. Even if the nodes show

default_warehouse

in the status list, they may be registered to the system but not yet allocated to the warehouse's compute pool. How to Fix You need to manually add the Compute Nodes (CN) to your warehouse. Use the following steps: 1. Get the CN host and heartbeat port from the

IP

and

HeartbeatPort

columns of your

SHOW COMPUTE NODES;

output. 2. Add the nodes to the warehouse:

sql
    ALTER WAREHOUSE default_warehouse ADD COMPUTE NODES ("<ip1>:<heartbeat_port1>", "<ip2>:<heartbeat_port2>", ...);

Example:

sql
    ALTER WAREHOUSE default_warehouse ADD COMPUTE NODES ("10.0.0.1:9050", "10.0.0.2:9050");

3. Verify the change: Run

SHOW WAREHOUSES;

again. The

NodeCount

should now reflect the number of nodes you added. Why this happens In StarRocks 3.x+, the "Multi-Warehouse" architecture separates node registration from node allocation: * `ALTER SYSTEM ADD COMPUTE NODE`: Registers the hardware into the cluster. * `ALTER WAREHOUSE ... ADD COMPUTE NODES`: Assigns those registered resources to a specific compute group (Warehouse) for query execution. Additional troubleshooting * Check Warehouse State: Ensure the warehouse is in the

RUNNING

state in

SHOW WAREHOUSES

. * Session Warehouse: Ensure your current session is actually using the warehouse where the nodes were added:

sql
    SELECT current_warehouse();
    -- If it's different or null, set it:
    SET warehouse = 'default_warehouse';

* FE Configuration: If you are trying to use multi-warehouse features, ensure

enable_multi_warehouse = true

is set in your

fe.conf

(though it is often enabled by default in newer versions). References • deployment/upgrade.md • deployment/deploy_manually.md • quick_start/shared-data.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • deployment/shared_data/hdfs.md