SR 2.3.0版本 Failed to acquire globalStateMgr lock. Try again

SR 2.3.0版本偶发事件建表报: java.sql.SQLSyntaxErrorException: Failed to acquire globalStateMgr lock. Try again

大概出现概率万分之几概率

建表语句:
create table p00002_a.ds_boss_monthly_idx_stat ( data_day string,data_year_month string,idx_no integer,index_name string,idx_type string,unit string,is_standard varchar(48),up_to_standard bigint,not_up_to_standard bigint,flag string,cumulative_room string,idx_no_10 decimal(15,4),idx_no_20 decimal(15,4),idx_no_30 decimal(15,4),idx_no_40 decimal(15,4),idx_no_50 decimal(15,4),idx_no_60 decimal(15,4),idx_no_70 decimal(15,4),idx_no_80 decimal(15,4),idx_no_90 decimal(15,4),idx_no_100 decimal(15,4),idx_no_110 decimal(15,4),idx_no_120 decimal(15,4),idx_no_130 decimal(15,4),idx_no_140 decimal(15,4),idx_no_150 decimal(15,4),idx_no_160 decimal(15,4),idx_no_170 decimal(15,4),idx_no_180 decimal(15,4),idx_no_190 decimal(15,4),idx_no_200 decimal(15,4),idx_no_210 decimal(15,4),idx_no_280 decimal(15,4),idx_no_290 decimal(15,4),idx_no_530 decimal(15,4),idx_no_540 decimal(15,4),idx_no_550 decimal(15,4),idx_no_560 decimal(15,4),idx_no_570 decimal(15,4),idx_no_580 decimal(15,4),idx_no_590 decimal(15,4),idx_no_600 decimal(15,4),idx_no_610 decimal(15,4),idx_no_620 decimal(15,4),idx_no_630 decimal(15,4),idx_no_640 decimal(15,4),idx_no_650 decimal(15,4),idx_no_660 decimal(15,4),idx_no_670 decimal(15,4),idx_no_680 decimal(15,4),idx_no_690 decimal(15,4),idx_no_700 decimal(15,4),idx_no_710 decimal(15,4),idx_no_720 decimal(15,4),idx_no_730 decimal(15,4),idx_no_740 decimal(15,4),budget_10 decimal(15,4),budget_20 decimal(15,4),budget_30 decimal(15,4),budget_40 decimal(15,4),budget_50 decimal(15,4),budget_60 decimal(15,4),budget_70 decimal(15,4),budget_80 decimal(15,4),budget_90 decimal(15,4),budget_100 decimal(15,4),budget_110 decimal(15,4),budget_120 decimal(15,4),budget_130 decimal(15,4),budget_140 decimal(15,4),budget_150 decimal(15,4),budget_160 decimal(15,4),budget_170 decimal(15,4),budget_180 decimal(15,4),budget_190 decimal(15,4),budget_200 decimal(15,4),budget_210 decimal(15,4),budget_280 decimal(15,4),budget_290 decimal(15,4),budget_530 decimal(15,4),budget_540 decimal(15,4),budget_550 decimal(15,4),budget_560 decimal(15,4),budget_570 decimal(15,4),budget_580 decimal(15,4),budget_590 decimal(15,4),budget_600 decimal(15,4),budget_610 decimal(15,4),budget_620 decimal(15,4),budget_630 decimal(15,4),budget_640 decimal(15,4),budget_650 decimal(15,4),budget_660 decimal(15,4),budget_670 decimal(15,4),budget_680 decimal(15,4),budget_690 decimal(15,4),budget_700 decimal(15,4),budget_710 decimal(15,4),budget_720 decimal(15,4),budget_730 decimal(15,4),budget_740 decimal(15,4),idx_no_10_year decimal(38,4),idx_no_10_last_year_month decimal(38,4),idx_no_20_year decimal(38,4),idx_no_30_year decimal(38,4),idx_no_40_year decimal(38,4),idx_no_50_year decimal(38,4),idx_no_60_year decimal(38,4),idx_no_70_year decimal(38,4),idx_no_80_year decimal(38,4),idx_no_90_year decimal(38,4),idx_no_100_year decimal(38,4),idx_no_110_year decimal(38,4),idx_no_120_year decimal(38,4),idx_no_130_year decimal(38,4),idx_no_140_year decimal(38,4),idx_no_150_year decimal(38,4),idx_no_160_year decimal(38,4),idx_no_170_year decimal(38,4),idx_no_530_year decimal(38,4),idx_no_540_year decimal(38,4),idx_no_550_year decimal(38,4),idx_no_560_year decimal(38,4),idx_no_570_year decimal(38,4),idx_no_580_year decimal(38,4),idx_no_590_year decimal(38,4),idx_no_600_year decimal(38,4),idx_no_610_year decimal(38,4),idx_no_620_year decimal(38,4),idx_no_630_year decimal(38,4),idx_no_640_year decimal(38,4),idx_no_650_year decimal(38,4),idx_no_660_year decimal(38,4),idx_no_670_year decimal(38,4),idx_no_680_year decimal(38,4),idx_no_690_year decimal(38,4),idx_no_700_year decimal(38,4),idx_no_710_year decimal(38,4),idx_no_720_year decimal(38,4),idx_no_730_year decimal(38,4),idx_no_740_year decimal(38,4),budget_10_year decimal(38,4),budget_20_year decimal(38,4),budget_30_year decimal(38,4),budget_40_year decimal(38,4),budget_50_year decimal(38,4),budget_60_year decimal(38,4),budget_70_year decimal(38,4),budget_80_year decimal(38,4),budget_90_year decimal(38,4),budget_100_year decimal(38,4),budget_110_year decimal(38,4),budget_120_year decimal(38,4),budget_130_year decimal(38,4),budget_140_year decimal(38,4),budget_150_year decimal(38,4),budget_160_year decimal(38,4),budget_170_year decimal(38,4),budget_530_year decimal(38,4),budget_540_year decimal(38,4),budget_550_year decimal(38,4),budget_560_year decimal(38,4),budget_570_year decimal(38,4),budget_580_year decimal(38,4),budget_590_year decimal(38,4),budget_600_year decimal(38,4),budget_610_year decimal(38,4),budget_620_year decimal(38,4),budget_630_year decimal(38,4),budget_640_year decimal(38,4),budget_650_year decimal(38,4),budget_660_year decimal(38,4),budget_670_year decimal(38,4),budget_680_year decimal(38,4),budget_690_year decimal(38,4),budget_700_year decimal(38,4),budget_710_year decimal(38,4),budget_720_year decimal(38,4),budget_730_year decimal(38,4),budget_740_year decimal(38,4),tenant_id string ) engine=olap duplicate key(data_day) distributed by hash(tenant_id) buckets 4 properties(“replication_num” = “3”,“in_memory” = “false”,“storage_format” = “DEFAULT”)

什么原因导致的? 有什么方法可以规避下

您好,请问您的数据库有多少个库和多少张表?

2000张表左右,服务器配置6台(16core * 64G SSD),3FE、6BE 其中有三台fe和be混部 fe分配8G内存

请问您建这个表前进行了什么操作?例如把这个表DROP TABLE,接着马上就CREATE TABLE等等。

是的,针对全量模型可能会有表修改操作,统一先drop table force

是因为drop table 后立即create 造成的? 还是要中间间隔0.5s?

执行得较频繁和较快就有可能出现,请您多个DDL操作时间加点时延,最好相隔3秒吧。

好的, 我试试,多谢

这个问题最近又出现了

还是hive外部表,这个表不存在drop 、create太快的场景。同一时间点扎堆出现了五六个这种情况,监控也看了这时间点也没什么太高负载的情况,唯一高一点的就是image

咱们版本是2.3.0 建议先升级2.3.3

锁的问题先升级2.3.3,如果再出现麻烦通知我们,谢谢!

目前是2.3.2版本。等后面升级到2.3.3再看看吧