【详述】上周建了几个有CG属性的表，导完数据后用explain+待查询SQL确认colocate join生效，实测查询速度也比原来快了接近一倍左右，但这周再次查询相同SQL发现速度慢了很多，才发现colocate join 失效退化为了普通查询，后续发现建的三个colocate group的IsStable 全都变为false的状态
【背景】新建了几个表并导入了数据，但新建的表和已创建成功的colocate group里的表没有任何关系，导入数据后有一节点个磁盘使用量达到76%，第二多的一个节点的使用量达到68%，其他节点全都在50%以下
【业务影响】join 操作变慢
【StarRocks版本】2.1.1 arm架构 64位版
【集群规模】例如：3fe+40be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡 48C/512G/千兆
【附件】
-
IsStable为false时，表示当前 Group 内有部分表的分片正在做修复或迁移，此时，相关表的 Colocate Join 将退化为普通 Join。 SHOW PROC ‘/cluster_balance’;看下
我遇到的情况是SHOW PROC ‘/cluster_balance’ 命令看了没有修复的tablet和pending的tablet，但是istable还是false，这种情况是为什么呢？
是在fe leader节点执行的吗？SHOW PROC ‘/cluster_balance’ 这个在fe leader节点执行结果截个图看看
我是通过dbeaver连接后执行的，host有三个fe的ip，不知道是在哪个节点执行的
你通过mysql客户端直接在fe的leader节点执行看看结果
谢谢，我连上leader节点后执行了两次SHOW PROC ‘/cluster_balance’ 显示如下
两次执行间隔了几分钟，为啥pending_tablets的数量会变大？还有我发现当集群在负载均衡时，建表很容易超时，是因为负载均衡里创建tablet和删除tablet用的队列和建表创建tablet的队列是同一个吗？
等待修复或者迁移的tabet太多了，需要排队，不是一个队列，超时的话可以看看be.warning日志找下原因
