@Rocky java.sql.SQLSyntaxErrorException: Build Exec OlapScanNode fail, scan info is invalid what does error mean we are getting we are using fe-cn node

The error

java.sql.SQLSyntaxErrorException: Build Exec OlapScanNode fail, scan info is invalid

usually indicates that the StarRocks Frontend (FE) is unable to find any healthy compute resources (Backends or Compute Nodes) to execute the data scan for your table. This typically happens in one of the following scenarios: 1. No Healthy CN/BE Nodes If you are using a FE-CN architecture (likely StarRocks 3.0+ Shared-Data or a cluster using Compute Nodes), the FE must have active nodes to assign the scan task to. If all CN nodes are down or the FE has lost contact with them, it cannot build the execution plan. How to check: Run the following commands in your MySQL client:

sql
-- If using Compute Nodes
SHOW COMPUTE NODES;

-- If using traditional Backends
SHOW BACKENDS;

* Check the

Alive

column: It must be

true

for your nodes. * Check the

Heartbeat

status: Ensure the FE is successfully communicating with the CNs. 2. Tablet or Replica Issues For internal OLAP tables, if all replicas of a specific tablet are corrupted or offline, the FE cannot find a valid "scan info" (location of data) to provide to the execution engine. How to check:

sql
-- Check the health of the table's tablets
ADMIN SHOW REPLICA STATUS FROM <table_name>;

Look for any tablets where the status is not

OK

. If you see "Missing" or "Inconsistent" replicas, this is likely the cause. 3. Metadata Inconsistency Sometimes, after a node restart or a network glitch, the FE's view of the tablet locations might be outdated. Suggested Actions: 1. Restart the CN nodes: Ensure they are properly registered with the FE. 2. Verify Networking: Ensure the FE can reach the CN nodes on the

heartbeat_service_port

(default 9050) and

brpc_port

(default 8060). 3. Check FE Logs: Look at

fe.log

and

fe.warn.log

for more detailed stack traces. Search for "OlapScanNode" or the specific table name to see why it failed to find scan ranges. 4. Database/Table Health If the table was recently created or modified (e.g., a schema change failed), the metadata might be in an invalid state. Try running a simple

DESC <table_name>

or querying a different table to see if the issue is isolated. Rocky's recommendation: Start by running

SHOW COMPUTE NODES;

. If you see nodes marked as

Alive: false

, check the logs on those CN nodes (

cn.out

or

cn.log

) to see why they are failing to heartbeat with the FE. References • faq/Sql_faq.md • faq/Others.md • release_notes/release-2.5.md • release_notes/release-3.1.md • faq/loading/Broker_load_faq.md • sql-reference/System_variable.md

but why suddenly it happens ? @Rocky we havent changed any version or any cn node was down in past days

It is common to see sudden issues in a stable StarRocks environment even when no version changes or node outages have occurred. Typically, this is because the internal state of the cluster or the characteristics of your data have crossed a threshold. Here are the most likely reasons why this happens "suddenly": 1. Tablet Version Limit (Compaction Backlog) This is the most frequent cause of sudden query failures. If you are loading data frequently (e.g., many small routine loads or inserts), StarRocks creates new "versions" (rowsets) for each tablet. * The Threshold: By default, if a tablet exceeds 1000 versions, queries will fail with a "too many versions" error because the system can't merge them fast enough. * How to check:

sql
    -- Find tablets with high rowset counts
    SELECT BE_ID, TABLET_ID, NUM_ROWSET
    FROM information_schema.be_tablets
    WHERE NUM_ROWSET > 700;

* Why it's sudden: Compaction works in the background. You might have been out-pacing it for days, and only just hit the 1000-version hard limit. 2. Memory & Resource Pressure Even without a version change, your data volume growth or query patterns might have finally exhausted available memory. * BE Memory: If a BE node hits its memory limit, it may start killing queries or trigger the OOM (Out of Memory) killer. * FE JVM GC: The Frontend (FE) manages metadata. As your data grows (more tablets/metadata), the FE's Java Heap might experience Full GC, leading to sudden "Planner use long time" errors or connection timeouts. * How to check: Check

fe.gc.log

for long pause times or

<http://be.INFO|be.INFO>

for memory-related warnings. 3. Disk Space and I/O Saturation If your data disks reach 90% utilization, StarRocks may stop accepting new data or slow down significantly to protect the system. * Why it's sudden: A specific large load or a log file buildup could have pushed the disk over the 90% threshold. * How to check: Run

SHOW BACKENDS\G

and check the

DataUsedCapacity

and

DiskStat

columns. 4. Data Skew and Outdated Statistics The Cost-Based Optimizer (CBO) relies on statistics to generate efficient query plans. * Stale Stats: If your data distribution has changed significantly and

ANALYZE

hasn't run recently, the optimizer might suddenly choose a very poor execution plan (e.g., a massive Shuffle instead of a Broadcast join). * Tablet Skew: One tablet might have grown much larger than others, creating a bottleneck for parallel processing. 5. Background "Schema Change" or "Clone" Tasks Sometimes background maintenance tasks (like replica repair or an unfinished

ALTER TABLE

) can suddenly consume significant IO and CPU. * How to check:

sql
    SHOW ALTER COLUMN; -- Check for active schema changes
    SHOW PROC '/statistic'; -- Check for "UnhealthyTabletNum"

To give you a more specific answer, could you share the exact error message you are seeing in your logs or query output? You can usually find the most detailed error in the

fe.audit.log

or the

be.WARNING

logs of the involved nodes. References • faq/Sql_faq.md • faq/Others.md • administration/management/monitoring/alert.md • using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md

how can we fix ? @Rocky

To help you fix the issue, I’ll need a bit more information! Could you please share: 1. The specific error message you are seeing (e.g., from your SQL client or application). 2. The query or operation you were performing when the issue occurred. 3. The context, such as whether this is a performance issue, a syntax error, or a connectivity problem. In the meantime, here are a few general places to look for clues: * FE Logs: Check

fe/log/fe.warn.log

for metadata or query planning issues. * BE Logs: Check

be/log/be.WARNING

for execution or storage-related errors. * Common Errors: Many SQL errors (like

1064

for syntax or

5024

for timeouts) have specific causes. Please paste the error or describe the problem, and I'll be happy to find the solution for you! References • developers/development-environment/dev-env-setup.md • deployment/deploy_manually.md • developers/type_checker_xml_configuration.md • sql-reference/Error_code.md