Databases 4 min read

Accelerating StarRocks Node Decommissioning via tablet_sched_slot_num_per_path Tuning

The author decommissioned three StarRocks nodes with over 1M tablets each; default replica migration moved only 200k replicas in 24 hours, so they increased tablet_sched_slot_num_per_path from 2 to 32 per disk during off-peak, achieving 800k+ replicas migrated per node in 8 hours while monitoring disk I/O.

Lakehouse Research Base
Lakehouse Research Base
Lakehouse Research Base
Accelerating StarRocks Node Decommissioning via tablet_sched_slot_num_per_path Tuning

Problem: Slow Replica Migration During Node Decommissioning

When decommissioning three nodes in a StarRocks storage-compute integrated cluster, each node contained over 1 million tablets. After initiating decommission, only 200,000 replicas had migrated after 24 hours, threatening the decommission schedule.

Root Cause: Default Slot Limits for Replica Scheduling

According to StarRocks documentation, replica repair and balancing tasks are scheduled via slots per disk. By default, each disk is allocated 2 slots for replica repair ( tablet_sched_slot_num_per_path) and 2 separate slots for balancing. A clone task consumes one slot on both source and destination disks. When slots are exhausted, no new tasks are assigned, limiting parallelism.

Solution: Increase tablet_sched_slot_num_per_path During Off-Peak Hours

The author increased the slot count from the default 2 to 32 per disk to boost parallel replica migration.

Step 1: Check Default Value

MySQL [bigdata]> ADMIN SHOW FRONTEND CONFIG LIKE '%tablet_sched_slot_num_per_path%';
+--------------------------------+------------------------------+-------+------+-----------+---------+
| Key                            | AliasNames                   | Value | Type | IsMutable | Comment |
+--------------------------------+------------------------------+-------+------+-----------+---------+
| tablet_sched_slot_num_per_path | [schedule_slot_num_per_path] | 2     | int  | true      |         |
+--------------------------------+------------------------------+-------+------+-----------+---------+
1 row in set (0.00 sec)

Step 2: Increase Slot Count to 32

# Increase to accelerate balancing [monitor disk I/O]
ADMIN SET FRONTEND CONFIG ("tablet_sched_slot_num_per_path" = "32");

Step 3: Monitor Disk I/O

Disk I/O utilization during replica migration
Disk I/O utilization during replica migration

Disk I/O utilization on some nodes reached 100% but did not remain saturated for extended periods.

Result: 4x Faster Decommissioning

Starting from the configuration change, the three nodes completed automatic decommissioning within 8 hours. Each node migrated over 800,000 replicas on average, compared to only 200,000 in the first 24 hours under default settings.

Key Takeaway

For large-scale node decommissioning in StarRocks, temporarily raising tablet_sched_slot_num_per_path during low-traffic windows can dramatically accelerate replica migration. Monitor disk I/O to avoid sustained saturation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

StarRocksperformance tuningdatabase administrationreplica migrationstorage-compute integrationnode decommissioningtablet_sched_slot_num_per_path
Lakehouse Research Base
Written by

Lakehouse Research Base

Focused on technical sharing in the data field, covering a tech stack that includes Hadoop, Spark, Flink, Kafka, Fluss, Paimon, Iceberg, StarRocks, ClickHouse, ES, Milvus, and more. Welcome to follow.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.