@Rocky Starrocks 3.5.20 shared-data mode running on k8s through kubernetes operator. When attempting to run SHOW MATERIALIZED VIEWS I am getting:

Getting analyzing error. Detail message: RepoExecutorexecute sql failed: WITH MaxStartRunID AS (    SELECT        task_name,        cast(history_content_json->'startTaskRunId' as string) start_run_id    FROM _statistics_.task_run_history     WHERE (task_name, create_time) IN (            SELECT task_name, MAX(create_time)            FROM _statistics_.task_run_history            WHERE TRUE AND  get_json_string(history_content_json, 'dbName') = 'default_cluster:test_db' AND  task_name IN ('mv-10171','mv-10214','mv-10256','mv-10301')            GROUP BY task_name    ) ) SELECT t.history_content_json FROM _statistics_.task_run_history t JOIN MaxStartRunID msr   ON t.task_name = msr.task_name   AND cast(t.history_content_json->'startTaskRunId' as string) = msr.start_run_id ORDER BY t.create_time DESC.

This error occurs because the internal query that

SHOW MATERIALIZED VIEWS

uses to retrieve refresh history from the system database (

_statistics_

) is failing. In StarRocks 3.3 and later, this command queries the

_statistics_.task_run_history

table to provide the

last_refresh_state

and other metadata. When you see

RepoExecutor execute sql failed

, it means the Frontend (FE) tried to run a background SQL query to gather this info, but the query execution itself encountered an error. Potential Causes and Solutions 1. System Table Inconsistency or Corruption The

_statistics_.task_run_history

table might not have been initialized correctly or may have been corrupted, especially during a version upgrade or a K8s deployment where the cluster was not fully ready when the table was created. * Check the table existence:

sql
    DESC _statistics_.task_run_history;

* Test the query manually: Try running the query from the error message yourself (replacing the MV names if necessary) to see the specific error:

sql
    SELECT count(*) FROM _statistics_.task_run_history;

If this fails with "Table not found" or a schema error, you may need to recreate the statistics tables. Note that the

_statistics_

database is managed by StarRocks; manually dropping tables here should be done with caution. 2. No Healthy Backends (BEs) / Compute Nodes (CNs) In shared-data mode, system tables are still stored as data. If the FE cannot find any alive BEs/CNs to execute the query against the

_statistics_

table, the

RepoExecutor

will fail. * Check node status:

sql
    SHOW BACKENDS; -- or SHOW COMPUTE NODES;

Ensure that the

Alive

status is

true

for your nodes. 3. Known Issues in K8s / Shared-Data In some scenarios, the

_statistics_

database is created with properties (like

replication_num

) that aren't compatible with the available nodes in a small K8s cluster, or there is an "available capacity" error during its creation. * Check the FE logs (

fe.log

and

fe.warn.log

) for the timestamp of the error. Look for a more detailed stack trace. You are looking for a

SemanticException

or a

AnalysisException

that precedes the

RepoExecutor

failure message. * If you see "Cluster has no available capacity" in the logs, it means the system table couldn't be initialized because of storage/node constraints. 4. JSON Column Issues The query uses

history_content_json->'startTaskRunId'

. If you have very old metadata or if a previous version of StarRocks wrote malformed JSON to this column, the

cast(... as string)

might fail. * If the command fails only when certain MVs exist, check those specific MVs. Recommended Next Steps 1. Inspect FE Logs: This is the most critical step. The "Detail message" you provided is a summary; the

fe.log

will contain the underlying cause (e.g.,

TABLE_NOT_FOUND

,

NOT_ALIVE_BACKEND

, or a specific JSON parsing error). 2. Verify statistics Health: Run

SELECT * FROM _statistics_.task_run_history LIMIT 1;

. If this fails, the system table is the problem. 3. Community Support: Since 3.5.20 is a very recent version, if the logs show a

NullPointerException

or a syntax error in the internal SQL, it may be a bug. I recommend reporting the full log trace to the StarRocks Slack or opening a GitHub issue. References • sql-reference/sql-statements/materialized_view/SHOW_MATERIALIZED_VIEW.md • using_starrocks/async_mv/materialized_view_task_run_details.md • sql-reference/information_schema/materialized_views.md

@Rocky - trying to run SELECT count(*) FROM statistics.task_run_history fails with starlet err [RequestID=18CB12604D7AC8D3][StatusCode=503]Get object s3://starrocks/b3b1abe8-a6e6-4fc0-9289-d88f589a7359/db10025/10041/10349/meta/0000000000002870_0000000000000002.meta error: Unable to parse ExceptionName: XMinioServerNotInitialized Message: Server not initialized yet, please try again.: BE:10003

The error

XMinioServerNotInitialized

(HTTP 503) indicates that the MinIO server is not ready to handle requests. In StarRocks shared-data mode, all table data and system metadata (like the task history for MVs) reside in the object store. If the storage layer is offline or uninitialized, StarRocks cannot function. What this means Your StarRocks BE (Backend) tried to fetch a metadata file from MinIO, but MinIO responded that it is still in its initialization phase. This is common in Kubernetes environments if: * MinIO is restarting: One or more MinIO pods are in a

CrashLoopBackOff

or still starting. * Distributed MinIO Handshake: If you are running a distributed MinIO cluster, the pods may have started, but they haven't yet reached a "quorum" or finished the internal handshake required to serve data. * Storage Locking: A previous crash might have left stale locks or metadata that MinIO is struggling to reconcile upon startup. Troubleshooting Steps 1. Check MinIO Pod Status Check the health of your MinIO deployment in K8s:

bash
kubectl get pods -n <your-minio-namespace>
kubectl logs <minio-pod-name> -n <your-minio-namespace>

Look for errors like

Unable to initialize server

,

Waiting for all other servers to be up

, or disk-related permission errors in the MinIO logs. 2. Verify StarRocks BE Connectivity From within one of the StarRocks BE/CN pods, try to

curl

the MinIO endpoint to see if it's reachable and what it returns:

bash
# Example
curl <http://minio-service-address:9000/minio/health/live>

If this returns a 503 or fails to connect, the issue is purely at the network/storage level. 3. Inspect BE Logs for Detail Check the

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

or

be.WARNING

logs on the BE reporting the error (in your case,

BE:10003

). It may provide more context on whether this is a persistent failure or a intermittent timeout. 4. Shared-Data Configuration If MinIO is actually healthy, verify that your StarRocks

storage_volume

or

run_mode

configuration hasn't changed. If you recently updated the MinIO credentials or endpoint, ensure the StarRocks FE has the updated info:

sql
SHOW STORAGE VOLUMES;
-- Ensure the 'IsDefault' volume has the correct endpoint and 'Enabled' is true.

Why does this affect

SHOW MATERIALIZED VIEWS

? Starting with StarRocks 3.3,

SHOW MATERIALIZED VIEWS

queries the internal

_statistics_.task_run_history

table to show you the "Last Refresh" status. Because this table's data is stored in MinIO, the command fails entirely if the connection to MinIO is broken. Summary: This is an infrastructure/storage issue. You need to ensure your MinIO cluster is fully "Initialized" and healthy before StarRocks can execute queries or administrative commands.