tablet 不能动态平衡

💬 StarRocks 用户问答
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】
大佬，

  1. 帮忙排查下 21日还没有平衡完，主要原因是什么？
  2. 帮忙排查下 21日 大表 ods_fact_event_user rename 成 ods_fact_event_user_bak_20260417 之后，balance 一直不成功的原因？

存算一体集群，原本有5台be，tablet 原先在 410w左右，3月31日新增了3台be，到4月21日，老的be 350w左右，新的 150w左右。一直都27日也没啥变化，tablet一直没有平衡，而且21日之后发现be会有一些 clone failed 报错，tablet 指向的是一个没有分区的大表（4.5TB）, 但是21日的时候平衡基本属于停滞状态。

大表：ods_fact_event_user_bak_20260417 的 tablet 查询结果

image
image1961×313 31.7 KB

参数目前的设置情况：
tablet_sched_disable_balance = false
tablet_sched_balance_load_disk_safe_threshold = 0.1
tablet_sched_balance_load_score_threshold = 0.01
schedule_slot_num_per_path = 16
tablet_sched_max_scheduling_tablets = 15000
tablet_sched_repair_delay_factor_second = 30
parallel_clone_task_per_path = 16

麻烦排查下是什么问题？

【背景】无
【业务影响】
【是否存算分离】
【StarRocks版本】存算一体 3.2.12-3faf7d4
【集群规模】3fe + 8be
【机器信息】fe 96c/374g be 32c/247g
【附件】
fe日志：
felog.7z (20.3 MB)

be日志：
felog.7z (20.3 MB)

be warring 日志：
felog.7z (20.3 MB)

be.INFO 我们保留的太短，日志还挺多，看下是否可以看出问题？

#2

我去 够震撼的，单个tablet 500GB…

#3

这个之前没有用分区，给的分桶还很少，日积月累这么大。目前能设置分桶大点吗？

CREATE TABLE ods_fact_event_user_bak_20260417 (
distinct_id varchar(1048576) NULL COMMENT “”,
devicecode varchar(1048576) NULL COMMENT “”,
type varchar(1048576) NULL COMMENT “”,
time datetime NULL COMMENT “”,
event varchar(1048576) NULL COMMENT “”,
uuid varchar(1048576) NULL COMMENT “”,
ip varchar(1048576) NULL COMMENT “”,
cpid bigint(20) NULL COMMENT “”,
app_id varchar(1048576) NULL COMMENT “”,
product_id varchar(1048576) NULL COMMENT “”,
platform_id bigint(20) NULL COMMENT “”,
channel_id varchar(1048576) NULL COMMENT “”,
sub_channel_id varchar(1048576) NULL COMMENT “”,
create_time datetime NULL COMMENT “”,
properties varchar(1048576) NULL COMMENT “”,
partition bigint(20) NULL COMMENT “”,
offset bigint(20) NULL COMMENT “”,
#distinct_old varchar(65533) NULL COMMENT “”,
#rx_region_tag varchar(65533) NOT NULL DEFAULT “” COMMENT “”,
#role_id varchar(65533) NOT NULL DEFAULT “” COMMENT “”
) ENGINE=OLAP
DUPLICATE KEY(distinct_id)
COMMENT “OLAP”
DISTRIBUTED BY HASH(distinct_id) BUCKETS 3
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“enable_persistent_index” = “false”,
“replicated_storage” = “false”,
“fast_schema_evolution” = “true”,
“compression” = “ZSTD”
);

#4

大佬，能修改分桶吗？

#5

我设置

ALTER TABLE ods_fact_event_user_bak_20260417 DISTRIBUTED BY HASH(`distinct_id`) BUCKETS 150 ;

但是查询 show create table ods_fact_event_user_bak_20260417; 还是 3个分桶，没有生效呢？

#6

玩不转，StarRocks根本拉不动这个tablet，

show partitions from ods_fact_event_user_bak_20260417 ; 返回结果发出来看看

#7

image
image2385×179 15.1 KB

#8

image
image1614×83 9.61 KB

fe 日志中有一条相关信息：

2026-04-29 11:33:23.485+08:00 INFO (leaderCheckpointer|125435) [TaskRun.initStatus():315] init task status, task:optimize-_120456195_ods_fact_event_user_bak_20260417_120456195, query_id:920081e7-4374-11f1-9cda-00163e4b2f94, create_time:1777430336997

我11点半修改成150个分桶，后台目前有个查询，这个超时时间是多少？需要怎么查询这个后台任务？或者取消能行吗？

#9

show alter table optimize from 库名 where TableName=‘ods_fact_event_user_bak_20260417’
你看看有没有结果。

另外你这个全量表，4.5TB建成一个全量表，就一个分区这个设计就有很大的问题。查都查不动吧。分桶数按照DataSize 1GB=1~10个Buckets标准，你想想4.5TB应该分多少个bucket，起码得500个才行。 :joy:

#10

能查到，看到超时是 86400，目前 current_queries 查询到是数据已经扫了1.983TB，那这个需要取消掉吗？重新分配 500个分桶？

image
image1626×494 20.2 KB

#11

能取消吗？

#12

CANCEL ALTER TABLE OPTIMIZE FROM 库名.表名

#13

嗯，取消掉了，不过 current_queries 还在

#14

建议你建一个新表，这个分表分桶数是500，然后一点点的把旧表的数据挪到新表这边来。你现在这个量级和分桶数已经极度偏差了，继续提交alter命令修改分桶数不是明智的选择，在balance的时候很容易造成集成负压。

#15

慢慢等它恢复吧，这是异步任务，它需要时间。只要你手动提交cancel就行。考虑挪数据吧。

#16

好的，确实太大了
还有个问题，如果我们项迁移集群（存算一体迁移到存算一体），这个表会不会迁移不成功？

#17

如果是想一步到位，90%几率会失败。估计查都查不动，可以考虑按照某个日期逻辑表达式慢慢挪。

#18

但如果这个表的分桶数是200以上的话，迁移和查询都没有压力。

#19

好的，我重新建表，然后挪数据吧

京ICP备2022026421号-1