@Rocky we suddenly started getting: Build Exec OlapScanNode fail, scan info is invalid for one of the tables in StarRocks shared nothing cluster (v4.0.10)

The error "Build Exec OlapScanNode fail, scan info is invalid" typically indicates that the StarRocks FE (Front-End) planner is unable to find any healthy or queryable replicas for one or more tablets in the table you are querying. This often happens when the FE thinks all available replicas are "bad" or when there is a metadata inconsistency between the FE and the BE (Back-End) nodes. Common Causes 1. Missing or Unhealthy Replicas: If you have a single-replica table (

replication_num = 1

) and the BE hosting that replica goes down or the tablet becomes corrupt, the data is unavailable. 2. Metadata Inconsistency: The FE leader might have stale information about tablet health. In some cases, a bug or race condition causes the FE to mark replicas as abnormal incorrectly. 3. Failed Publish Version: High-concurrency loads or timeouts during the "publish" phase can lead to tablets having inconsistent versions, making them unqueryable. 4. Backend Issues: If BE nodes are marked as

Alive: false

or are in the process of being decommissioned/dropped, the planner may fail to locate a valid scan range. Troubleshooting Steps Run the following commands in your MySQL client to identify the root cause: 1. Check for abnormal tablets Run this to see if there are any tablets marked as "unhealthy" in your cluster:

sql
SHOW PROC '/statistic';

Look for columns like

UnhealthyTabletNum

. If the number is greater than 0, there is a data availability issue. 2. Locate specific failing tablets If the table name is

my_table

, check the status of its tablets:

sql
SHOW TABLET FROM my_table;

Check the

IsBad

column and compare the

Version

across replicas. If a tablet has no healthy replicas, the query will fail with the error you saw. 3. Check BE Node Status Ensure all backends are alive and functional:

sql
SHOW BACKENDS;

Verify that

Alive

is

true

and

SystemDecommissioned

is

false

. 4. Check FE Logs The FE leader log (

fe.log

or

fe.warn.log

) usually contains a more detailed error message right before the

Build Exec OlapScanNode fail

trace, such as: *

Failed to get scan range, no queryable replica found in tablet <tablet_id>

*

Compute node not found

Potential Fixes * Restart the FE Leader: If

SHOW PROC '/statistic'

shows abnormal replicas but you are certain the BEs and data are healthy, this may be a metadata sync issue. Restarting the FE Leader can sometimes force a refresh of the metadata. * Check Replication: If you are using

replication_num = 1

, consider increasing it to at least 3 for production tables to prevent single-point-of-failure issues. * Repair Tablet: If a specific tablet is marked as bad, you may need to wait for the FE to automatically schedule a repair (clone from another replica) or manually intervene if it's a single-replica table. If you can provide the output of

SHOW PROC '/statistic'

or any specific tablet errors from the FE logs, I can provide more specific guidance. References • faq/Sql_faq.md • release_notes/release-2.5.md • knowledge/admin_and_operation/shared_data_compaction.md

SHOW PROC '/statistic';
SHOW TABLET FROM my_table;
SHOW BACKENDS;
SHOW FRONTENDS;

all these are healthy. EXPLAIN command for a query itself is failing for that table @Rocky

The error "Build Exec OlapScanNode fail, scan info is invalid" occurs when the StarRocks FE (Front-End) planner tries to generate a query execution plan but cannot find any healthy or queryable replicas for the tablets involved. Even if

SHOW PROC '/statistic'

and

SHOW BACKENDS

look healthy, the FE leader might have a stale or inconsistent metadata cache regarding specific tablets. Recommended Troubleshooting Steps 1. Locate the failing Tablet ID When this error occurs, the FE usually logs a more descriptive warning right before the exception. Access the FE Leader's

fe.log

or

fe.warn.log

and search for:

"Failed to get scan range, no queryable replica found in tablet"

If you find a tablet ID (e.g.,

12345

), inspect it directly:

sql
SHOW TABLET 12345;

Check if the

IsBad

column is

true

or if the

Version

is significantly behind the others. 2. Check Replica Status Detail High-level statistics can sometimes miss version mismatches. Run this command to check for version or state errors across all replicas of that table:

sql
ADMIN SHOW REPLICA STATUS FROM your_table_name;

Look for columns like

VersionCount

or

State

. If any replicas show a

VersionError

, they won't be used for scanning. 3. Test Inconsistency Between FE Nodes If you have multiple FEs, connect to a different FE (e.g., an Observer or a different Follower) and run the

EXPLAIN

or the query. * If it works on other FEs but fails on the Leader, the Leader's metadata cache is likely stale. * If it fails on all FEs, there is a deeper metadata issue or a genuine lack of healthy replicas for a specific partition. 4. Verify Partition Metadata If the table is partitioned, check if a specific partition is missing tablets or has a

VisibleVersion

of 1 while the rest of the table is ahead:

sql
SHOW PARTITIONS FROM your_table_name;

Potential Solutions * Restart the FE Leader: This is the most common fix for "ghost" metadata issues where the cluster appears healthy but the planner is stuck. Restarting the Leader forces a metadata reload from the BDBJE log. * Set Tablet to Bad: If you identified a specific tablet/replica that is problematic (via step 1 or 2), you can manually mark it as bad to force StarRocks to repair it from other healthy replicas:

sql
    ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "12345", "backend_id" = "10001", "status" = "bad");

_Note: Do not do this if you only have 1 replica (

replication_num = 1

)._ * Recover Tablet (For single-replica): If you are running with

replication_num = 1

and the replica is missing, you may need to restore from a backup or re-import the data for that partition. Are you using a single replica for this table? If so, this error usually indicates that the only BE node holding that data is reporting the tablet as unavailable or corrupted, even if the BE itself is "Alive". References • faq/Sql_faq.md • release_notes/release-2.5.md • administration/management/Check_tablet.md • sql-reference/sql-statements/administration/ADMIN_SHOW_REPLICA_STATUS.md • administration/management/Check_tablet.md • sql-reference/sql-statements/administration/ADMIN_SET_REPLICA_STATUS.md • sql-reference/sql-statements/data-definition/SHOW_PARTITIONS.md • administration/management/Check_tablet.md