企业官网建设流程全解析

杭州软件开发公司网站,百度seo公司哪家强一点,中国传统美食网页制作素材,天津做网页设计的公司文章目录问题场景根本原因分析1. BE 注册机制2. 问题发生的时序3. 代码流程分析3.1 BE 注册到 Leader FE3.2 Follower FE 同步 BE 信息3.3 容量检查逻辑为什么会出现这个问题#xff1f;原因1#xff1a;Follower 启动/同步延迟原因2#xff1a;Follower 的 journal replay …文章目录问题场景根本原因分析1. BE 注册机制2. 问题发生的时序3. 代码流程分析3.1 BE 注册到 Leader FE3.2 Follower FE 同步 BE 信息3.3 容量检查逻辑为什么会出现这个问题原因1Follower 启动/同步延迟原因2Follower 的 journal replay 卡住原因3BE 注册时 Follower 还没完全加入集群解决方案方案1等待 Follower 同步完成推荐方案2重启 Follower FE如果同步卡住预防措施1. 正确的启动顺序2. 监控 Follower 同步状态3. 确保网络连通性代码关键点总结快速诊断命令总结问题场景初始化流程先启动 3 个 FE1 Leader 2 Follower然后启动 3 个 BEBE 通过 MySQL 连接到 FE 并注册自己问题现象两个 Follower FE 报错Cluster has no available capacityLeader FE 可能正常能看到 BE根本原因分析1. BE 注册机制BE 启动时会通过MySQL 协议连接到 FE 并注册自己。关键点BE 只连接到指定的 FE通常是 Leader或配置的 helper FEBE 注册操作只在连接的 FE 上执行不会直接广播到所有 FEBE 注册信息通过 EditLog 同步到其他 FE2. 问题发生的时序时间线 T1: 启动 3 个 FE - FE1 成为 Leader - FE2, FE3 成为 Follower可能还在同步 journal T2: 启动 3 个 BE - BE1 连接到 Leader FE1注册成功 - BE2 连接到 Leader FE1注册成功 - BE3 连接到 Leader FE1注册成功 Leader FE1: - 执行 addBackend() → 更新 idToBackendRef - 记录到 EditLog: logAddBackend() - 此时 Leader 能看到 3 个 BE容量正常 T3: Follower FE2, FE3 的状态 - 如果 Follower 还没完全启动/同步完成 - 或者 Follower 的 journal replay 还没追上 - 它们可能还没 replay 到 BE 注册的 EditLog - 因此 idToBackendRef 还是空的或只有部分 BE - 导致 getClusterAvailableCapacityB() 返回 0 或很小 - 触发 Cluster has no available capacity 错误3. 代码流程分析3.1 BE 注册到 Leader FE当 BE 通过 MySQL 连接到 Leader FE 并执行注册时// SystemInfoService.addBackend() 方法第 203-224 行privatevoidaddBackend(Stringhost,intheartbeatPort){BackendnewBackendnewBackend(GlobalStateMgr.getCurrentState().getNextId(),host,heartbeatPort);// 1. 更新 Leader 的 idToBackendRef立即生效MapLong,BackendcopiedBackendsMaps.newHashMap(idToBackendRef);copiedBackends.put(newBackend.getId(),newBackend);idToBackendRefImmutableMap.copyOf(copiedBackends);// 2. 记录到 EditLog用于同步到 FollowerGlobalStateMgr.getCurrentState().getEditLog().logAddBackend(newBackend);LOG.info(finished to add {} ,newBackend);}关键点Leader 的idToBackendRef立即更新Leader 能立即看到 BEBE 注册信息记录到 EditLog需要时间同步到 Follower3.2 Follower FE 同步 BE 信息Follower FE 通过Replay EditLog来同步 BE 信息// SystemInfoService.replayAddBackend() 方法第 909-934 行publicvoidreplayAddBackend(BackendnewBackend){// 更新 Follower 的 idToBackendRefMapLong,BackendcopiedBackendsMaps.newHashMap(idToBackendRef);copiedBackends.put(newBackend.getId(),newBackend);idToBackendRefImmutableMap.copyOf(copiedBackendRef);// 添加到集群if(newBackend.getBackendState()BackendState.using){finalClusterclusterGlobalStateMgr.getCurrentState().getCluster();if(null!cluster){cluster.addBackend(newBackend.getId());}}}关键点Follower 的idToBackendRef只有在 Replay EditLog 时才会更新如果 Follower 的 journal replay还没追上就看不到新注册的 BE3.3 容量检查逻辑当 TableKeeper 或其他组件尝试创建表时// SystemInfoService.checkClusterCapacity() 方法第 1024-1028 行publicvoidcheckClusterCapacity()throwsDdlException{if(getClusterAvailableCapacityB()0L){thrownewDdlException(Cluster has no available capacity);}}// SystemInfoService.getClusterAvailableCapacityB() 方法第 1007-1022 行publiclonggetClusterAvailableCapacityB(){ListBackendclusterBackendsgetBackends();// 从 idToBackendRef 获取longcapacity0L;for(Backendbackend:clusterBackends){if(backend.isDecommissioned()){capacity-backend.getDataUsedCapacityB();}else{capacitybackend.getAvailableCapacityB();// 如果 BE 不在 idToBackendRef 中这里就是 0}}returncapacity;}关键点getBackends()从idToBackendRef获取 BE 列表如果 Follower 的idToBackendRef还是空的或只有部分 BE容量就是 0触发 “Cluster has no available capacity” 错误为什么会出现这个问题原因1Follower 启动/同步延迟场景Follower FE2, FE3 启动较慢或者还在 replay journalBE 注册时Follower 的 journal replay还没追上Follower 的idToBackendRef还是空的验证方法-- 在 Follower FE 上执行SHOWFRONTENDS;-- 查看 ReplayedJournalId如果比 Leader 小很多说明还在同步SHOWBACKENDS;-- 如果看不到 BE说明还没 replay 到 BE 注册的 EditLog原因2Follower 的 journal replay 卡住场景Follower 的 journal replay 遇到错误/异常卡在某个 journal ID无法继续 replay 后续的 BE 注册 EditLog导致 Follower 永远看不到新注册的 BE验证方法# 在 Follower FE 上查看日志tail-100 fe/log/fe.log|grep-ireplay\|error\|exception原因3BE 注册时 Follower 还没完全加入集群场景Follower FE2, FE3 虽然启动了但可能还没完全加入集群状态异常Leader 的 EditLog 可能还没同步到这些 Follower导致 Follower 看不到 BE验证方法-- 在 Leader FE 上执行SHOWFRONTENDS;-- 查看 Follower 的 Alive 状态和 ReplayedJournalId解决方案方案1等待 Follower 同步完成推荐操作等待 Follower FE 的 journal replay 追上 Leader确认 Follower 能看到所有 BE验证-- 在 Leader 上查看SHOWFRONTENDS;-- 确认 Follower 的 ReplayedJournalId 接近 Leader-- 在 Follower 上查看如果能连接SHOWBACKENDS;-- 确认能看到所有 BE等待时间通常需要1-5 分钟取决于 journal 数量方案2重启 Follower FE如果同步卡住操作停止 Follower FE使用 Leader 作为 helper 重新启动# 在 Follower FE 上执行./bin/stop_fe.sh# 使用 Leader 作为 helper 启动./bin/start_fe.sh --helperleader_ip:9010 --daemon# 查看启动日志等待同步完成tail-f log/fe.log|grep-ireplay\|ready\|transfer预防措施1. 正确的启动顺序推荐顺序先启动Leader FE等待完全启动再启动Follower FE等待完全启动并同步完成最后启动BE让 BE 注册到 Leader验证每个步骤-- 步骤1确认 Leader 启动SHOWFRONTENDS;-- 应该看到 1 个 Leader-- 步骤2确认 Follower 启动并同步SHOWFRONTENDS;-- 应该看到 1 Leader 2 Follower且 重要点ReplayedJournalId 接近-- 步骤3启动 BE 后在所有 FE 上验证SHOWBACKENDS;-- 所有 FE 都应该能看到 BE2. 监控 Follower 同步状态定期检查-- 在 Leader 上执行SHOWFRONTENDS;-- 关注-- - Follower 的 Alive 状态-- - ReplayedJournalId 是否接近 Leader-- - LastHeartbeat 是否正常3. 确保网络连通性检查Follower FE 能连接到 Leader FE9010 端口Follower FE 能连接到 BE9050 心跳端口Leader FE 能连接到所有 BE代码关键点总结BE 注册只在连接的 FE通常是 Leader上立即生效Leader 的idToBackendRef立即更新其他 FE 需要通过 EditLog Replay 才能看到Follower 的 BE 视图依赖 Journal ReplayreplayAddBackend()方法更新 Follower 的idToBackendRef如果 Replay 还没追上Follower 就看不到 BE容量检查基于本地的idToBackendRefgetClusterAvailableCapacityB()从idToBackendRef获取 BE 列表如果idToBackendRef为空容量就是 0触发错误快速诊断命令-- 1. 在 Leader 上检查 FE 状态SHOWFRONTENDS;-- 2. 在 Leader 上检查 BE 状态SHOWBACKENDS;-- 3. 在 Follower 上检查 BE 状态如果能连接SHOWBACKENDS;-- 4. 对比 Leader 和 Follower 的 ReplayedJournalId-- 如果差异很大说明 Follower 还在同步# 5. 在 Follower 上查看 journal replay 日志tail-100 fe/log/fe.log|grep-ireplay\|error\|exception# 6. 检查 Follower 到 Leader 的网络连通性nc-zvleader_ip9010总结问题本质Follower FE 的idToBackendRef还没同步到 BE 注册信息导致容量检查失败。根本原因BE 注册信息通过 EditLog 同步如果 Follower 的 journal replay 还没追上就看不到 BE。解决方法等待 Follower 同步完成或重启 Follower 使其从 Leader 重新同步。预防措施按正确顺序启动Leader → Follower → BE并确保 Follower 完全同步后再启动 BE。