starrocks 查询字符串函数偶现报错Backend node not found. Check if any backend node is down.backend: [xx.27 alive: true inBlacklist: false] [xx.26 alive: false inBlacklist: false]

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】偶现的BE crash,某个用例导致了BE crash,BE进程挂掉,当前我们服务的逻辑是当检测到集群异常后,会再把异常的节点重新拉起,当该节点异常重新拉起还未ADD到集群的过程中,其他当时正在该节点执行的用例会受到影响,会报错该节点不是alive,或者inBlacklist:true。
【背景】 对应的语句为

query_id:e1796330-5863-11ef-9d5d-286ed4893e30

SELECT LOWER(UPPER(query_data_file_csv.string_01)) AS re\nFROM dte_hive_catalog._default.ry_data_file_csv_173404fd070550f1f9ea435d36d98ec2 AS query_data_file_csv\nORDER BY query_data_file_csv.string_01

query_id:9cc48a4f-5862-11ef-880a-286ed4899978

SELECT RTRIM(’ bbb ') AS TRIMTmp, RTRIM(l.string_01) AS re1, RTRIM(r.string_01) AS re2\nFROM dte_hive_catalog._default.ry_data_file_csv_173404fd070550f1f9ea435d36d98ec2 AS l\nINNER JOIN (SELECT query_data_olap.__time, query_data_olap.count, query_data_olap.string_01, query_data_olap.string_02, query_data_olap.string_03, query_data_olap.string_04, query_data_olap.string_05, query_data_olap.string_06, query_data_olap.string_07, query_data_olap.string_08, query_data_olap.string_09, query_data_olap.string_10, query_data_olap.integer_01, query_data_olap.integer_02, query_data_olap.integer_03, query_data_olap.integer_04, query_data_olap.integer_05, query_data_olap.integer_06, query_data_olap.integer_07, query_data_olap.integer_08, query_data_olap.integer_09, query_data_olap.integer_10, query_data_olap.long_01, query_data_olap.long_02, query_data_olap.long_03, query_data_olap.long_04, query_data_olap.long_05, query_data_olap.long_06, query_data_olap.long_07, query_data_olap.long_08, query_data_olap.long_09, query_data_olap.long_10, query_data_olap.float_01, query_data_olap.float_02, query_data_olap.float_03, query_data_olap.float_04, query_data_olap.float_05, query_data_olap.float_06, query_data_olap.float_07, query_data_olap.float_08, query_data_olap.float_09, query_data_olap.float_10, query_data_olap.double_01, query_data_olap.double_02, query_data_olap.double_03, query_data_olap.double_04, query_data_olap.double_05, query_data_olap.double_06, query_data_olap.double_07, query_data_olap.double_08, query_data_olap.double_09, query_data_olap.double_10\nFROM dte_druid_catalog.default_db.ODAEDATASET__DEFAULT_query_data_olap__DEFAULT AS query_data_olap) AS r ON TRUE\nWHERE r.__time > ‘2024-03-02 15:11:50’\nLIMIT 1
【业务影响】
【是否存算分离】否
【StarRocks版本】3.2.0
【集群规模】多机
【机器信息】
【联系方式】
【附件】
be.out.log (23.8 KB)

检查一下报错的query是否已经收到部分数据, 另外看看查询的表用的是几副本? replication_num设置的是多少?

收到部分数据是什么意思呢?就是query以后be就crash了。然后查询的是external catalog,没有副本的说法

先升级到3.2的最新小版本试试,如果还有我们我们一起看下

我们内部已经选型了3.2.0(某为),升级是很麻烦的事情,能不能帮忙看看是哪个pr解决的问题

我们只能通过回合代码的方式来解决这些问题

测试环境能复现吗?

先发个explain costs 吧。

麻烦帮忙看看呢explain costs1.txt (26.3 KB) explain costs2.txt (19.9 KB)

然后发现一个事情,问题是偶现的,是测试跑了很多用例之后有时候会出现,不是每次都执行一下那两个sql就会be crash。所以你们这边有没有关于BE crash的3.2.0没有带上的PR,我想着先把这些回合到我们内部呢?

导致肯定是由这两个语句导致的,be.out里面的堆栈就是这两个语句的,只是explain costs的时间点对不上,可能不太有用

upper[([57: float_02, FLOAT, true] 这里有问题

这是个物化视图吧,dte__DEFAULT__mv_col__test

是external catalog,Hive catalog。


不知道explain里面为啥会有部分mv,语句确实是通过hive catalog查hdfs上的csv文件

https://github.com/StarRocks/starrocks/commit/04e73f105f68321d6a565834af6f0cded59e589c

大佬,是这个MR解决了这个问题吗

这个确实是个物化视图,是不是合入你发的那个MR就可以解决这个问题了?然后想请问一下这个问题出现的原因是什么呢?为什么会是偶现的呀

是物化视图导致的,但是还不能完全确定是这个PR,再来个QUeryDump吧

costs1.txt 里面这个SQL的query dump