文章目录适用范围典型日志脱敏A) Cluster has no available capacityTableKeeper 创建内部表失败B) NoAliveBackendException / no alive backends这些错误“到底在检查什么”对应代码1) 为什么会报 Cluster has no available capacity2) 为什么会报 no alive backends / NoAliveBackendException最常见根因按优先级A) 该 FE 节点看到的 BE 状态/容量信息异常尤其“Leader 正常但某些节点报错”B) BE 心跳/端口/进程问题导致 Alivefalse 或容量不上报C) 容量确实为 0磁盘满/路径不可用排查步骤最短路径强烈推荐照做第 1 步在 **Leader** 上确认“集群真实状态”第 2 步在“报错的 FE 机器”确认它是否真的在同一个集群第 3 步检查报错 FE → BE 网络连通性非常高频修复步骤按根因对应处理修复 1报错节点没真正加入 FE 集群最常见“Leader 正常但它一直报错”修复 2BE 心跳端口登记错误典型把 9060 当成心跳修复 3BE 端口拒绝连接 / BE 未监听Connection refused修复 4容量确实不足磁盘满/路径问题验证修复后 12 分钟内应达成适用范围本文仅针对两类问题的排查与修复FE 后台线程常见为TableKeeper周期性报错Cluster has no available capacity业务/后台任务报错com.starrocks.common.NoAliveBackendException: No alive backend或no alive backends文档已对IP/节点名/ClusterId做脱敏统一用占位符表示FE_LEADER_IP、FE_FOLLOWER_IP、BE_IP等。典型日志脱敏A)Cluster has no available capacityTableKeeper 创建内部表失败TS ERROR (TableKeeper|TID) [RepoExecutor.executeDDL():LINE] execute DDL error: CREATE TABLE IF NOT EXISTS loads_history ... com.starrocks.sql.analyzer.SemanticException: Getting analyzing error. Detail message: Cluster has no available capacity. at com.starrocks.system.SystemInfoService.checkClusterCapacity(SystemInfoService.java:LINE) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.createTable(LocalMetastore.java:LINE) ~[starrocks-fe.jar:?] ...B)NoAliveBackendException/no alive backendscom.starrocks.common.NoAliveBackendException: No alive backend或com.starrocks.common.DdlException: no alive backends这些错误“到底在检查什么”对应代码1) 为什么会报Cluster has no available capacity建表前会调用容量校验当 FE 视角下的集群可用容量≤ 0 \le 0≤0时直接拒绝建表public long getClusterAvailableCapacityB() { ListBackend clusterBackends getBackends(); long capacity 0L; for (Backend backend : clusterBackends) { // Here we do not check if backend is alive, // We suppose the dead backends will back to alive later. if (backend.isDecommissioned()) { capacity - backend.getDataUsedCapacityB(); } else { capacity backend.getAvailableCapacityB(); } } return capacity; } public void checkClusterCapacity() throws DdlException { if (getClusterAvailableCapacityB() 0L) { throw new DdlException(Cluster has no available capacity); } }要点这条校验与“能不能选到 Alive BE”不是同一件事它只看容量汇总结果。2) 为什么会报no alive backends/NoAliveBackendException在普通建表路径里如果Alive 的 BE 数量为 0直接抛no alive backendsprivate void buildPartitions(Database db, OlapTable table, ListPartition partitions) throws DdlException { if (partitions.isEmpty()) { return; } int numAliveBackends systemInfoService.getAliveBackendNumber(); if (numAliveBackends 0) { throw new DdlException(no alive backends); }在 Lake 相关任务里如果挑不到可用 BE会抛NoAliveBackendException语义一样找不到可用的 Alive BE。最常见根因按优先级A) 该 FE 节点看到的 BE 状态/容量信息异常尤其“Leader 正常但某些节点报错”典型场景Leader 能正常建表/写入/查询只有某些节点常见是“以为自己是 follower 的节点”在本机日志里刷no capacity/no alive backend高概率原因该节点并未真正加入 FE 集群在 Leader 上SHOW FRONTENDS;看不到它或该节点journal 未追平/处于异常恢复导致本地视角不完整或该节点到 BE 的网络不通Leader 能通但该节点不通B) BE 心跳/端口/进程问题导致 Alivefalse 或容量不上报常见表现SHOW BACKENDS中某些 BEAlivefalseErrMsg为Connection refused/timeout/Invalid method name: heartbeat端口字段为-1或容量字段异常C) 容量确实为 0磁盘满/路径不可用表现AvailCapacity接近 0或 BEstorage_root_path配置/权限/挂载异常导致容量上报异常排查步骤最短路径强烈推荐照做第 1 步在Leader上确认“集群真实状态”SHOWFRONTENDS;SHOWBACKENDS\G判断如果SHOW FRONTENDS只有 1 行仅 Leader说明你以为的 follower 很可能没入集群它本机报错不代表集群。如果SHOW BACKENDS\G里至少 1 台 BEAlivetrue且AvailCapacity很大集群实际有容量报错节点多半是“视角异常/不一致”。第 2 步在“报错的 FE 机器”确认它是否真的在同一个集群在报错 FE 节点本机连它自己执行SHOWFRONTENDS;对比 Leader 的输出如果该节点的 ClusterId/成员列表与 Leader 不一致它实际上在跑“另一个 FE 集群”或加入失败。第 3 步检查报错 FE → BE 网络连通性非常高频在报错 FE 节点上执行把BE_IP替换为任一 Alive 的 BEnc-zvBE_IP9050# heartbeat_service_portnc-zvBE_IP8060# brpc_portnc-zvBE_IP8040# webserver_port任何一个端口不通都可能导致BE 心跳失败AlivefalseBE 端口/容量无法刷新后台任务误判 no capacity / no alive backend修复步骤按根因对应处理修复 1报错节点没真正加入 FE 集群最常见“Leader 正常但它一直报错”在 Leader 上添加 followerALTERSYSTEMADDFOLLOWERFE_FOLLOWER_IP:9010;在该 follower 机器上推荐“干净加入”避免元数据不一致./bin/stop_fe.shmvmeta meta_bak_$(date%Y%m%d_%H%M%S)./bin/start_fe.sh--helperFE_LEADER_IP:9010--daemon回到 Leader 验证SHOWFRONTENDS;修复 2BE 心跳端口登记错误典型把 9060 当成心跳现象Invalid method name: heartbeat且HeartbeatPort显示为 9060。做法在 FE 上删除错误登记、用 9050 重新添加ALTERSYSTEMDROPBACKENDBE_IP:9060;ALTERSYSTEMADDBACKENDBE_IP:9050;修复 3BE 端口拒绝连接 / BE 未监听Connection refused在 BE 机器上ss-lntp|egrep:9050|:9060|:8040|:8060||netstat-tlnp|egrep:9050|:9060|:8040|:8060./bin/stop_be.sh ./bin/start_be.sh--daemontail-200be/log/be.INFO|grep-ierror\|exception\|fail修复 4容量确实不足磁盘满/路径问题在 BE 机器上检查storage_root_path配置是否正确检查磁盘空间df -h检查目录权限BE 用户可写验证修复后 12 分钟内应达成SHOWBACKENDS\GSHOWFRONTENDS;期望期望数量的 FE 全部在列且Alivetrue至少 1 台 BEAlivetrue并且AvailCapacity/TotalCapacity正常TableKeeper日志不再周期性刷Cluster has no available capacity备注TableKeeper属于周期任务修复后可能还会再打印 1-2 次历史错误然后停止。
