StarRocks日志太大了，每次上传都很不方便，能分段就好了
不过很奇怪啊，集群只挂了一个be，BI就查询不了了报错，不至于呀，为啥呢
导出日志
出错节点ID: [ 48b06869-67cd-53b5-50a6-6b35f5cfaa72 ]
java.util.concurrent.ExecutionException: com.finebi.common.exception.conf.table.FineSqlErrorException: 错误代码:62400001Backend not found. Check if any backend is down or not. backend: [10.1.100.99 alive: false inBlacklist: false] [10.1.100.90 alive: true inBlacklist: false] [10.1.100.91 alive: true inBlacklist: false] [10.1.100.93 alive: true inBlacklist: false]
I1103 16:54:57.829267 17253 daemon.cpp:188] Current memory statistics: process(189697741772), query_pool(157026921882), load(0), metadata(996139437), compaction(0), schema_change(0), column_pool(12855290879), page_cache(2376319520), update(0), chunk_allocator(1086285200), clone(0), consistency(0) 这个时间点附近有 large memory alloc的日志吗
分配内存超过10G的
I1103 16:49:40 到 16:55的日志，发下
看日志是一个大查询没防住，要分析下原因
但是有个问题，建的表都是有副本的，为什么只是挂了个be节点就查询报错，这样不就保证不了高可用
这个不符合预期，需要具体看下
还需要什么日志信息吗
加我下，我们详细沟通下，
1赞
你好，这个有找到具体的原因吗？
基本确实原因, set global enable_exchange_pass_through=false; 应该可以规避这个问题。
好的 多谢大佬
您好：
我这边在3.1.14版本也遇到了大查询没有防住的问题，也是关闭这个参数，就可以防止了。
想请问一下这个参数设置为true之后的具体作用，或者说对性能提升在哪方面？
想要了解一下关闭这个参数的影响。
或者有后续改进的issue吗？有的话，我也可以帮忙改，哈哈。
看这个pr优化还蛮多的，感觉是必须打开的
下周会提个PR，Fix这个问题
好的，感谢。我近期也关注一下相关的pr
请问一下，修复了吗？