3.3.12版本 修改分桶数 running状态执行了好10几个小时了 数据量很小

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】问题详细描述
数据量只有13万 分区750个 三节点三副本, 主键表 tablet数13000左右 大约每个分区6个分桶 主键表自动建的分桶 所以打算调整分桶数到1 降低tablet数量 从昨天晚上21点到现在还没执行完

CREATE TABLE dim_ldl_industry_category_filter (
category_name1 varchar(1048576) NOT NULL COMMENT “一级类目”,
yuce_market_category_id varchar(1048576) NOT NULL COMMENT “行情类目ID”,
stat_date datetime NOT NULL COMMENT “统计日期”,
__id bigint(20) NOT NULL AUTO_INCREMENT COMMENT “__id”,
category_name2 varchar(1048576) NULL COMMENT “二级类目”,
category_name3 varchar(1048576) NULL COMMENT “三级类目”,
last_category_name varchar(1048576) NULL COMMENT “叶子类目”,
dt varchar(1048576) NULL COMMENT “日分区”,
category_name4 varchar(1048576) NULL COMMENT “四级类目”
) ENGINE=OLAP
PRIMARY KEY(category_name1, yuce_market_category_id, stat_date, __id)
COMMENT “DIM_行业类目筛选信息表”
PARTITION BY (stat_date,yuce_market_category_id,category_name1)
DISTRIBUTED BY HASH(category_name1, yuce_market_category_id, stat_date, __id)
PROPERTIES (
“compression” = “ZSTD”,
“enable_persistent_index” = “true”,
“fast_schema_evolution” = “true”,
“replicated_storage” = “true”,
“replication_num” = “3”
);

【背景】做过哪些操作?
【业务影响】
【是否存算分离】
【StarRocks版本】例如:3.3.12
【集群规模】例如:3fe(1 follower+2observer)+5be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:48C/64G/万兆
【联系方式】为了在解决问题过程中能及时联系到您获取一些日志信息,请补充下您的联系方式,例如:社区群16-可乐鸡或者邮箱,谢谢
【附件】

直接建个新表,insert overwrite过去

感觉是分区的数据有频繁操作读写。

也没有一直写入 读取应该不影响吧 多版本原子性切换的话

ADMIN SHOW FRONTEND CONFIG LIKE ‘%max_scheduling_tablets%’;
ADMIN SHOW FRONTEND CONFIG LIKE ‘%disable_balance%’;
ADMIN SHOW FRONTEND CONFIG LIKE ‘%schedule_slot_num_per_path%’;
ADMIN SHOW FRONTEND CONFIG LIKE ‘%max_balancing_tablets%’;

看下参数值多少

没改过 mysql> ADMIN SHOW FRONTEND CONFIG LIKE “%max_scheduling_tablets%”;
±------------------------------------±-------------------------±------±-----±----------±--------+
| Key | AliasNames | Value | Type | IsMutable | Comment |
±------------------------------------±-------------------------±------±-----±----------±--------+
| tablet_sched_max_scheduling_tablets | [max_scheduling_tablets] | 10000 | int | true | |
±------------------------------------±-------------------------±------±-----±----------±--------+
1 row in set (0.01 sec)

mysql> ADMIN SHOW FRONTEND CONFIG LIKE “%disable_balance%”;
±-----------------------------±------------------±------±--------±----------±--------+
| Key | AliasNames | Value | Type | IsMutable | Comment |
±-----------------------------±------------------±------±--------±----------±--------+
| tablet_sched_disable_balance | [disable_balance] | false | boolean | true | |
±-----------------------------±------------------±------±--------±----------±--------+
1 row in set (0.00 sec)

mysql> ADMIN SHOW FRONTEND CONFIG LIKE “%schedule_slot_num_per_path%”;
±-------------------------------±-----------------------------±------±-----±----------±--------+
| Key | AliasNames | Value | Type | IsMutable | Comment |
±-------------------------------±-----------------------------±------±-----±----------±--------+
| tablet_sched_slot_num_per_path | [schedule_slot_num_per_path] | 8 | int | true | |
±-------------------------------±-----------------------------±------±-----±----------±--------+
1 row in set (0.00 sec)

mysql> ADMIN SHOW FRONTEND CONFIG LIKE “%max_balancing_tablets%”;
±-----------------------------------±------------------------±------±-----±----------±--------+
| Key | AliasNames | Value | Type | IsMutable | Comment |
±-----------------------------------±------------------------±------±-----±----------±--------+
| tablet_sched_max_balancing_tablets | [max_balancing_tablets] | 500 | int | true | |
±-----------------------------------±------------------------±------±-----±----------±--------+
1 row in set (0.00 sec)

没啥问题,grep 87118 fe.log 看下交易事件

fe.log.20250717-1:2025-07-17 21:29:15.168+08:00 INFO (schema change|17) [OptimizeJobV2.runPendingJob():204] transfer optimize job 251158 state to WAITING_TXN, watershed txn_id: 87118
三个节点只有一个日志

都还在等待交易,cancel掉重试下,再看看是否正常,确认是不是每次都这样,还是说仅仅是昨晚那个点有问题

刚才 cancel了 然后 重试 又等了10分钟 还是不行 我就新建表了

有点怀疑这个主键表是不是有频繁事务,要不你随便建一个临时表,再alter table改它分桶,看下会不会堵住?验一下。