Hi @Rocky , I have starrocks cluster deployed on no shared arch version 3.3.2 , the issue i am facing is after restoring the backup when i run my streaming job i get and publish timeout error

The "Publish Timeout" error in StarRocks typically means that your data has been successfully committed to the cluster, but the "publish" phase (which makes the data visible for querying) did not finish within the default timeout period (usually 30 seconds). This is common after a restore operation because the cluster is often under heavy background load while it synchronizes metadata and data files. Why this happens after a restore When you restore a backup, the Backend (BE) nodes perform several intensive background tasks: 1. Downloading Snapshots: Pulling data from the backup repository (e.g., S3 or HDFS). 2. Tablet Cloning/Recovery: Replicating tablets to ensure they meet the expected replication factor. 3. Compaction: Merging the newly restored rowsets. These tasks consume significant CPU, Disk IO, and network resources. When your streaming job tries to publish a new version, the BEs may be too busy to respond to the FE's "publish version" RPC in time. Troubleshooting and Solutions 1. Verify "Success" Status First, confirm the status of your load jobs. If the status is

Publish Timeout

, the data is safe and will eventually become visible once the background tasks catch up. You usually do not need to retry these specific loads. 2. Check Cluster Background Tasks Check if the cluster is still busy recovering from the restore: * Show Restore Status:

SHOW RESTORE;

(Ensure the state is

FINISHED

). * Check Tablet Health:

SHOW TABLET FROM <your_table_name>;

to see if any replicas are in a

RECOVERING

or

CLONING

state. * Check BE Background Tasks:

sql
    SHOW PROC '/backend_tasks';

Look for high numbers of

cloning

or

download

tasks. 3. Increase the Publish Timeout (FE) You can increase the time the Frontend waits for the BEs to finish publishing. This is a dynamic configuration in the FE:

sql
-- Increase from default (30s) to 120s or 300s
ADMIN SET FRONTEND CONFIG ("publish_version_timeout_second" = "120");

4. Flink Connector Settings (if applicable) If your streaming job is using the StarRocks Flink Connector, you may need to adjust the sink settings: *

<http://sink.publish-timeout.ms|sink.publish-timeout.ms>

: If you are using

sink.version = 'V2'

, set this to a higher value (e.g.,

120000

for 120 seconds). * Merge Commit: If you have enabled Merge Commit, ensure the

<http://sink.publish-timeout.ms|sink.publish-timeout.ms>

is set appropriately for your cluster's current load. 5. BE Thread Pool Adjustment If the cluster has many tablets or very high concurrency, you can check the publish worker thread pool on the BEs (

be.conf

): *

transaction_publish_version_worker_count

: Defaults to the number of CPU cores. Ensure BEs are not CPU-saturated. Summary If the restore just finished, the best course of action is often to wait for the cluster to stabilize (tablet states become

NORMAL

) or increase the

publish_version_timeout_second

to give the busy BEs more time to acknowledge the publish request. References • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/System_variable.md • loading/Flink-connector-starrocks.md • faq/operation_maintenance_faq.md