shared-data

Diagnose StarRocks shared-data cluster failures from BE and FE logs.

73|12|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/StarRocks/starrocks-debug-skills --skill shared-data
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: shared-data
Source: https://github.com/StarRocks/starrocks-debug-skills/tree/main/shared-data
Command: npx skills add https://github.com/StarRocks/starrocks-debug-skills --skill shared-data

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps diagnose and resolve StarRocks shared-data cluster incidents where reads, writes, compaction, or publish operations fail due to cache, storage, or leader-switch issues.

Core Features & Use Cases

  • Root-cause analysis: Distinguishes between DataCache autoscaling regressions, DataCache corruption, S3 rate limiting, FE leader-switch failures, and cached tablet metadata mismatches.
  • Evidence-driven troubleshooting: Uses BE and FE logs, cloud-native compaction history, cache metrics, and information_schema queries to pinpoint the failing subsystem.
  • Recovery guidance: Recommends targeted fixes such as restarting affected BEs, disabling risky cache behavior, tuning S3 prefix partitioning, or adjusting FE graceful-exit settings.
  • Use Case: A shared-data warehouse suddenly shows rising compaction score and slow queries, and this Skill traces the issue to cache eviction before suggesting the exact corrective configuration changes.

Quick Start

Use the shared-data skill to classify the incident, inspect the relevant logs and metrics, and provide the safest recovery steps for the affected StarRocks cluster.

Frequently Asked Questions about shared-data

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does my StarRocks lake-mode cluster show slow queries and a rising compaction score?

FE leader-switch publish failures in StarRocks shared-data deployments typically happen due to cached tablet metadata inconsistencies or incomplete graceful-exit configurations. Inspecting FE logs and querying information_schema reveals the specific metadata mismatch blocking the publish operation.

How do I troubleshoot S3 multipart upload and rate-limiting errors in shared-data StarRocks?

Troubleshooting S3 rate-limiting and multipart upload errors in StarRocks shared-data clusters involves checking BE logs for S3 exceptions and evaluating cloud-native storage metrics. Tuning S3 prefix partitioning and adjusting connection limits resolves the storage bottlenecks.

What is the best way to recover a StarRocks shared-data cluster from DataCache corruption?

Recovering from DataCache corruption in StarRocks lake-mode clusters requires analyzing cache metrics to identify the failure, restarting affected BE nodes, and disabling risky cache behaviors through targeted configuration changes to restore stable read operations.

Does troubleshooting StarRocks shared-data incidents require access to both BE and FE logs?

StarRocks lake-mode deployments face edge cases like DataCache autoscaling regressions and cached tablet metadata mismatches. When compaction or publish operations fail, checking cloud-native compaction metrics and FE graceful-exit settings identifies the failing subsystem.