表达式分区自动删除分区失效

【详述】表达式分区自动删除分区失效
【背景】

请问大佬 ,为什么我的表不会自动清除过期分区? 设置192个小时分区,目前涨到4百多了
使用的是表达式分区 ,应该如何排查问题?

show create table dc_span 的结果是

CREATE TABLE dc_span (
startTime datetime NOT NULL COMMENT “”,
serviceId varchar(120) NOT NULL COMMENT “”,
serviceInstance varchar(50) NOT NULL COMMENT “”,
resource varchar(500) NOT NULL COMMENT “”,

) ENGINE=OLAP
DUPLICATE KEY(startTime, serviceId)
PARTITION BY date_trunc(‘hour’, startTime)
DISTRIBUTED BY HASH(serviceId, serviceInstance, resource)
PROPERTIES (
“replication_num” = “1”,
“in_memory” = “false”,
“enable_persistent_index” = “false”,
“replicated_storage” = “true”,
“partition_live_number” = “192”,
“compression” = “LZ4”
);

【业务影响】
【是否存算分离】否
【StarRocks版本】3.2.4
【集群规模】1fe 1be
【机器信息】
【联系方式】社区群13-tempo
【附件】

show partitions from dc_span; 看下结果是否正常

能够正常查询
另外 我这个表是有经过swap替换过的
ALTER TABLE dc_span SWAP WITH dc_span_bak;
另外还有建立mv ,不知道有没有影响?

show proc ‘/dbs/$db_id’ 这个路径的统计信息估计有问题,我们这边先看一下

1赞

show partitions from table; 这个结果也是 400多个分区么,不是 192个分区?

400多的 上面截图有显示

mv是同步物化视图还是异步物化视图,如果加上mv的分区是否刚好是show partitions 返回的结果

是异步的 建立了两张

我再次建立另一张bak ,将原表述句insert into后 ,原子替换表 ,把旧表删除 , 现在发现还是没有自动删除分区
我该如何排查? 表结构跟开头相同 都是设置8天 192个小时 过期

在fe.log 中 grep “DynamicPartitionScheduler” 看下有没有异常日志

有的

grep DynamicPartitionScheduler fe.warn.log*
fe.warn.log:2024-04-03 11:13:36,376 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executeDynamicPartitionForTable():382] Automatically removes the schedule because table does not exist, tableId: 148940
fe.warn.log:2024-04-03 11:53:36,399 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executeDynamicPartitionForTable():382] Automatically removes the schedule because table does not exist, tableId: 1080931
fe.warn.log.20240402-1:2024-04-02 12:33:01,826 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=876363 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 12:33:01,826 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=196785 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 12:52:14,196 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=876363 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 12:52:14,197 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=196785 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 20:32:49,911 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=876363 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 20:32:49,912 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=196785 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 21:43:35,885 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=876363 have no ttl. remove it from scheduler
fe.warn.log.20240402-1:2024-04-02 21:43:35,885 WARN (DynamicPartitionScheduler|52) [DynamicPartitionScheduler.executePartitionTimeToLive():503] database=10005, table=196785 have no ttl. remove it from schedule

看下现在删除不掉分区的表的 tableid,在fe的日志中有没有相关异常信息
show proc ‘/dbs/$db_id’

目前是有看到
fe.warn.log:2024-04-07 03:02:45,627 WARN (starrocks-mysql-nio-pool-2988|91556) [CacheDictManager.hasGlobalDict():184] get dict cache for 876363: hostname failed
fe.warn.log:2024-04-07 03:40:45,813 WARN (thrift-server-pool-65787|91865) [CacheDictManager.getGlobalDict():289] get dict cache for 876363: type failed
等等字段上的错误

另外发现
SHOW DYNAMIC PARTITION TABLES
没有dc_span表

请问 表达式分区 不支持动态删除 或者查询状态吗?

这个问题怎样了?后来有解决吗?我也碰到一样的问题了,同样是表达式date_trunc按小时分区,设置保留192个分区,但没有自动清除过期分区。我这没有建mv。版本是3.2.4

反馈下进展:
查看show create table,参数里面确实是有"partition_live_number"的,从日志看也出现了相同的"database=xxx, table=xxx have no ttl. remove it from scheduler"
后来通过alter table set (“partition_live_number”=“192”)的方式,成功触发了ttl机制。
为何创建table的时候声明了不生效,仍然原因不明。
但有需要的其他人,可以用alter table作为临时规避的方法重新设置一遍ttl

请问是 alter table吗? 好像没看到update table set的语句?

ALTER TABLE [<db_name>.]<tbl_name>
SET (“key” = “value”,…)

是的,是alter table,抱歉写错了。感谢提醒,已经编辑了回答了

目前发现,只有执行alter的当天生效,但后面又失效了, 请问有发生同样问题吗?

我这边没碰到。你观测下是不是FE重启了,我怀疑有什么地方存在bug,重启的时候并没有读取成功配置。