StarRocks 黑名单查询SHOW BACKEND/COMPUTE NODE BLACKLIST 语句详解【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks导读当集群中部分 BEBackend或 CNCompute Node节点因网络故障、连接超时导致查询频繁失败时StarRocks 提供 BE/CN 黑名单机制来将问题节点临时隔离出查询调度。本文以SHOW BACKEND/COMPUTE NODE BLACKLIST语句为核心讲解如何查询当前 BE 与 CN 黑名单中的节点、解读返回字段的含义并结合 FE 端 HostBlacklist.java 的源码实现与 Config.java 配置项说明黑名单的自动维护原理与可调参数。读完本文你将能熟练查看黑名单状态、区分手动/自动拉黑节点并为集群故障排查提供依据。适用版本与前置条件BE 黑名单自 StarRocks v3.3.0 起支持CN 黑名单自 v4.0 起支持。执行SHOW BACKEND/COMPUTE NODE BLACKLIST需要拥有SYSTEM 级别的BLACKLIST权限否则无法执行。每个 FE 节点维护自己独立的 BE/CN 黑名单不会与其他 FE 节点共享。因此在多个 FE 节点上执行该语句时返回结果可能各不相同这一点在多 FE 部署环境下排查时需特别注意。完整的黑名单管理说明参见 Manage BE and CN Blacklist。语法SHOW { BACKEND | COMPUTE NODE } BLACKLISTSHOW BACKEND BLACKLIST查询当前 FE 节点上的 BE 黑名单。SHOW COMPUTE NODE BLACKLIST查询当前 FE 节点上的 CN 黑名单shared-data 存算分离架构下使用。返回字段说明执行后返回一张表包含以下四列返回字段说明BackendId/ComputeNodeId被拉黑的 BE/CN 节点 ID。BE ID 可通过SHOW BACKENDS获取CN ID 可通过SHOW COMPUTE NODES获取AddBlackListType节点进入黑名单的方式。MANUAL表示由用户手动执行ADD BACKEND/COMPUTE NODE BLACKLIST加入AUTO表示由 StarRocks 检测到连接异常后自动加入LostConnectionTime对MANUAL类型表示节点被手动加入黑名单的时间对AUTO类型表示该节点最后一次成功建立连接的时间LostConnectionNumberInPeriod在CheckTimePeriod(s)时间周期内检测到的断连次数CheckTimePeriod(s)StarRocks 检查黑名单中 BE/CN 节点连接状态的周期其值取 FE 配置项black_host_history_sec的取值单位为秒字段背后的实现逻辑从源码来看返回的每一行数据由HostBlacklist.getShowData()方法生成HostBlacklist.java其数据来源是内存中的两张结构hostBlacklistMapLong, DisconnectEvent当前仍处于黑名单中的节点键为节点 IDeventHistoryLinkedListDisconnectEvent按时间线记录的断连事件流水最多保留HISTORY_SIZE 1000条HostBlacklist.java。其中LostConnectionNumberInPeriod的计算方式是过滤eventHistory中节点 ID 与当前节点一致的断连事件并计数HostBlacklist.java而CheckTimePeriod(s)直接读取Config.black_host_connect_failures_within_time所在时间段对应的black_host_history_sec值输出。另外可以注意到一个细节查询展示时getShowData()会通过GlobalStateMgr的ClusterInfo校验节点是否仍存在于集群中如果该节点已从集群下线getBackend/getComputeNode返回空则不会出现在查询结果里HostBlacklist.java。也就是说已下线节点不会一直滞留在黑名单查询结果中。使用示例-- 查看 BE 黑名单 SHOW BACKEND BLACKLIST; ---------------------------------------------------------------------------------------------------- | BackendId | AddBlackListType | LostConnectionTime | LostConnectionNumberInPeriod | CheckTimePeriod(s) | ---------------------------------------------------------------------------------------------------- | 10001 | MANUAL | 2024-04-28 11:52:09 | 0 | 5 | ---------------------------------------------------------------------------------------------------- -- 查看 CN 黑名单 SHOW COMPUTE NODE BLACKLIST; -------------------------------------------------------------------------------------------------------- | ComputeNodeId | AddBlackListType | LostConnectionTime | LostConnectionNumberInPeriod | CheckTimePeriod(s) | -------------------------------------------------------------------------------------------------------- | 10005 | MANUAL | 2025-08-18 10:47:51 | 0 | 5 | --------------------------------------------------------------------------------------------------------示例解读示例中两个节点均为MANUAL类型说明是管理员手动拉黑的节点。LostConnectionNumberInPeriod为 0表示在当前检查周期内没有新的断连事件对于手动拉黑的节点这通常意味着节点长期保持被隔离状态。CheckTimePeriod(s)为 5表示black_host_history_sec被配置为 5 秒。注意示例输出中的CheckTimePeriod(s)值为 5而代码默认值为 120即 2 分钟示例为演示性输出实际取值以你的 FE 配置为准。黑名单自动管理机制与相关 FE 配置了解查询语句之后理解它背后“为什么节点会进入黑名单”同样重要这有助于正确解读查询结果。管理文档 Manage BE and CN Blacklist 说明了以下自动管理逻辑每次 BE/CN 节点与 FE 节点失去连接或在 BE/CN 上执行的查询因超时而失败时FE 节点都会将该节点加入其 BE/CN 黑名单。FE 会持续评估黑名单中节点的连通性统计其在一定时间窗口内的连接失败次数。只有当黑名单节点的连接失败次数低于预设阈值时StarRocks 才会将其移出黑名单。手动拉黑的节点MANUAL类型不会被自动移出黑名单必须由管理员手动执行DELETE BACKEND/COMPUTE NODE BLACKLIST移除。自动管理行为由以下三个 FE 配置项控制均在 Config.java 中定义且均为ConfField(mutable true)支持运行时动态修改无需重启 FEFE 配置项默认值说明black_host_history_sec2 * 60120 秒黑名单节点断连事件的保留时间窗口即CheckTimePeriod(s)字段的值来源black_host_connect_failures_within_time5在black_host_history_sec时间窗口内允许黑名单节点出现的连接失败次数阈值超过该阈值则继续留在黑名单black_host_penalty_min_ms500毫秒节点进入黑名单后的最短停留时间避免节点因快速“进-出”黑名单而产生抖动源码级的自动维护流程FE 端通过 HostBlacklist.java 实现黑名单的自动维护其核心是一个名为UpdateBlacklistThread的后台守护线程继承自FrontendDaemon每 1000 毫秒1 秒执行一次refresh()HostBlacklist.java。refresh()的流程如下HostBlacklist.java清理过期历史调用updateHistory()删除eventHistory中早于当前时间black_host_history_sec秒的断连事件HostBlacklist.java。检查惩罚期对每个黑名单节点计算disconnectTime black_host_penalty_min_ms作为惩罚结束时间。若当前时间尚未超过惩罚期则节点继续保持黑名单状态避免节点进出黑名单过于频繁HostBlacklist.java。探测恢复对于AUTO类型的黑名单节点若节点在集群中可用checkNodeAvailable则通过NetUtils.checkAccessibleForAllPorts同时探测其bePort、brpcPort、httpPort三个端口HostBlacklist.java全部可达才认为节点恢复。决策去留对探测恢复的节点统计其在历史事件中的断连次数若次数小于black_host_connect_failures_within_time则将其移出黑名单否则继续保留HostBlacklist.java。清理下线节点若节点已从集群中移除getBackendOrComputeNode返回空直接从黑名单中移除HostBlacklist.java。值得说明的是黑名单的写入规则addByManual()手动拉黑直接以TYPE_MANUAL覆盖写入hostBlacklist而add()自动拉黑通过compute保证自动拉黑不会覆盖手动拉黑的记录HostBlacklist.java。同时refresh()中只有AUTO类型的节点才会被自动移出黑名单HostBlacklist.java这与文档中“手动拉黑的节点不会被自动移除”的说明完全一致。测试验证相关单元测试位于 BackendBlacklistTest.java 与 SimpleSchedulerTest.java源码注释中也注明HostBlacklist的单元测试均位于SimpleSchedulerTest。其中BackendBlacklistTest覆盖了SHOW BACKEND BLACKLIST、ADD/DELETE BACKEND BLACKLIST等语句的解析与执行路径可以作为理解该功能行为的参考用例。相关 SQL 语句黑名单功能是一组配套语句SHOW语句通常与以下语句配合使用ADD BACKEND/COMPUTE NODE BLACKLIST手动将 BE/CN 节点加入黑名单DELETE BACKEND/COMPUTE NODE BLACKLIST手动将 BE/CN 节点移出黑名单SHOW BACKENDS获取 BE 节点列表与 BE IDSHOW COMPUTE NODES获取 CN 节点列表与 CN ID典型排障流程示例-- 1. 查看当前黑名单中有哪些节点 SHOW BACKEND BLACKLIST; -- 2. 对 AUTO 类型且 LostConnectionNumberInPeriod 持续增长的节点进一步确认其网络状态 -- 结合 SHOW BACKENDS 检查该节点的 IP、端口与心跳信息 SHOW BACKENDS\G -- 3. 若节点网络已恢复但故障期间反复断连次数超过阈值可手动确认后将其移出黑名单 -- DELETE BACKEND BLACKLIST BackendId;小结SHOW BACKEND/COMPUTE NODE BLACKLIST是查看 StarRocks BE/CN 黑名单状态的唯一入口。通过它你可以区分节点是被管理员手动拉黑MANUAL还是被系统自动拉黑AUTO观察断连次数与检查周期从而判断集群中是否存在持续失联的节点。结合 FE 配置项black_host_history_sec、black_host_connect_failures_within_time与black_host_penalty_min_ms可以按业务容忍度调整自动恢复节奏而背后的 HostBlacklist.java 实现则保证了“手动拉黑优先、自动恢复仅针对 AUTO 节点、节点下线自动清理”等关键语义为集群在高可用场景下的查询稳定性提供了保障。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 StarRocks 黑名单查询：SHOW BACKEND/COMPUTE NODE BLACKLIST 语句详解
StarRocks 黑名单查询SHOW BACKEND/COMPUTE NODE BLACKLIST 语句详解【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks导读当集群中部分 BEBackend或 CNCompute Node节点因网络故障、连接超时导致查询频繁失败时StarRocks 提供 BE/CN 黑名单机制来将问题节点临时隔离出查询调度。本文以SHOW BACKEND/COMPUTE NODE BLACKLIST语句为核心讲解如何查询当前 BE 与 CN 黑名单中的节点、解读返回字段的含义并结合 FE 端 HostBlacklist.java 的源码实现与 Config.java 配置项说明黑名单的自动维护原理与可调参数。读完本文你将能熟练查看黑名单状态、区分手动/自动拉黑节点并为集群故障排查提供依据。适用版本与前置条件BE 黑名单自 StarRocks v3.3.0 起支持CN 黑名单自 v4.0 起支持。执行SHOW BACKEND/COMPUTE NODE BLACKLIST需要拥有SYSTEM 级别的BLACKLIST权限否则无法执行。每个 FE 节点维护自己独立的 BE/CN 黑名单不会与其他 FE 节点共享。因此在多个 FE 节点上执行该语句时返回结果可能各不相同这一点在多 FE 部署环境下排查时需特别注意。完整的黑名单管理说明参见 Manage BE and CN Blacklist。语法SHOW { BACKEND | COMPUTE NODE } BLACKLISTSHOW BACKEND BLACKLIST查询当前 FE 节点上的 BE 黑名单。SHOW COMPUTE NODE BLACKLIST查询当前 FE 节点上的 CN 黑名单shared-data 存算分离架构下使用。返回字段说明执行后返回一张表包含以下四列返回字段说明BackendId/ComputeNodeId被拉黑的 BE/CN 节点 ID。BE ID 可通过SHOW BACKENDS获取CN ID 可通过SHOW COMPUTE NODES获取AddBlackListType节点进入黑名单的方式。MANUAL表示由用户手动执行ADD BACKEND/COMPUTE NODE BLACKLIST加入AUTO表示由 StarRocks 检测到连接异常后自动加入LostConnectionTime对MANUAL类型表示节点被手动加入黑名单的时间对AUTO类型表示该节点最后一次成功建立连接的时间LostConnectionNumberInPeriod在CheckTimePeriod(s)时间周期内检测到的断连次数CheckTimePeriod(s)StarRocks 检查黑名单中 BE/CN 节点连接状态的周期其值取 FE 配置项black_host_history_sec的取值单位为秒字段背后的实现逻辑从源码来看返回的每一行数据由HostBlacklist.getShowData()方法生成HostBlacklist.java其数据来源是内存中的两张结构hostBlacklistMapLong, DisconnectEvent当前仍处于黑名单中的节点键为节点 IDeventHistoryLinkedListDisconnectEvent按时间线记录的断连事件流水最多保留HISTORY_SIZE 1000条HostBlacklist.java。其中LostConnectionNumberInPeriod的计算方式是过滤eventHistory中节点 ID 与当前节点一致的断连事件并计数HostBlacklist.java而CheckTimePeriod(s)直接读取Config.black_host_connect_failures_within_time所在时间段对应的black_host_history_sec值输出。另外可以注意到一个细节查询展示时getShowData()会通过GlobalStateMgr的ClusterInfo校验节点是否仍存在于集群中如果该节点已从集群下线getBackend/getComputeNode返回空则不会出现在查询结果里HostBlacklist.java。也就是说已下线节点不会一直滞留在黑名单查询结果中。使用示例-- 查看 BE 黑名单 SHOW BACKEND BLACKLIST; ---------------------------------------------------------------------------------------------------- | BackendId | AddBlackListType | LostConnectionTime | LostConnectionNumberInPeriod | CheckTimePeriod(s) | ---------------------------------------------------------------------------------------------------- | 10001 | MANUAL | 2024-04-28 11:52:09 | 0 | 5 | ---------------------------------------------------------------------------------------------------- -- 查看 CN 黑名单 SHOW COMPUTE NODE BLACKLIST; -------------------------------------------------------------------------------------------------------- | ComputeNodeId | AddBlackListType | LostConnectionTime | LostConnectionNumberInPeriod | CheckTimePeriod(s) | -------------------------------------------------------------------------------------------------------- | 10005 | MANUAL | 2025-08-18 10:47:51 | 0 | 5 | --------------------------------------------------------------------------------------------------------示例解读示例中两个节点均为MANUAL类型说明是管理员手动拉黑的节点。LostConnectionNumberInPeriod为 0表示在当前检查周期内没有新的断连事件对于手动拉黑的节点这通常意味着节点长期保持被隔离状态。CheckTimePeriod(s)为 5表示black_host_history_sec被配置为 5 秒。注意示例输出中的CheckTimePeriod(s)值为 5而代码默认值为 120即 2 分钟示例为演示性输出实际取值以你的 FE 配置为准。黑名单自动管理机制与相关 FE 配置了解查询语句之后理解它背后“为什么节点会进入黑名单”同样重要这有助于正确解读查询结果。管理文档 Manage BE and CN Blacklist 说明了以下自动管理逻辑每次 BE/CN 节点与 FE 节点失去连接或在 BE/CN 上执行的查询因超时而失败时FE 节点都会将该节点加入其 BE/CN 黑名单。FE 会持续评估黑名单中节点的连通性统计其在一定时间窗口内的连接失败次数。只有当黑名单节点的连接失败次数低于预设阈值时StarRocks 才会将其移出黑名单。手动拉黑的节点MANUAL类型不会被自动移出黑名单必须由管理员手动执行DELETE BACKEND/COMPUTE NODE BLACKLIST移除。自动管理行为由以下三个 FE 配置项控制均在 Config.java 中定义且均为ConfField(mutable true)支持运行时动态修改无需重启 FEFE 配置项默认值说明black_host_history_sec2 * 60120 秒黑名单节点断连事件的保留时间窗口即CheckTimePeriod(s)字段的值来源black_host_connect_failures_within_time5在black_host_history_sec时间窗口内允许黑名单节点出现的连接失败次数阈值超过该阈值则继续留在黑名单black_host_penalty_min_ms500毫秒节点进入黑名单后的最短停留时间避免节点因快速“进-出”黑名单而产生抖动源码级的自动维护流程FE 端通过 HostBlacklist.java 实现黑名单的自动维护其核心是一个名为UpdateBlacklistThread的后台守护线程继承自FrontendDaemon每 1000 毫秒1 秒执行一次refresh()HostBlacklist.java。refresh()的流程如下HostBlacklist.java清理过期历史调用updateHistory()删除eventHistory中早于当前时间black_host_history_sec秒的断连事件HostBlacklist.java。检查惩罚期对每个黑名单节点计算disconnectTime black_host_penalty_min_ms作为惩罚结束时间。若当前时间尚未超过惩罚期则节点继续保持黑名单状态避免节点进出黑名单过于频繁HostBlacklist.java。探测恢复对于AUTO类型的黑名单节点若节点在集群中可用checkNodeAvailable则通过NetUtils.checkAccessibleForAllPorts同时探测其bePort、brpcPort、httpPort三个端口HostBlacklist.java全部可达才认为节点恢复。决策去留对探测恢复的节点统计其在历史事件中的断连次数若次数小于black_host_connect_failures_within_time则将其移出黑名单否则继续保留HostBlacklist.java。清理下线节点若节点已从集群中移除getBackendOrComputeNode返回空直接从黑名单中移除HostBlacklist.java。值得说明的是黑名单的写入规则addByManual()手动拉黑直接以TYPE_MANUAL覆盖写入hostBlacklist而add()自动拉黑通过compute保证自动拉黑不会覆盖手动拉黑的记录HostBlacklist.java。同时refresh()中只有AUTO类型的节点才会被自动移出黑名单HostBlacklist.java这与文档中“手动拉黑的节点不会被自动移除”的说明完全一致。测试验证相关单元测试位于 BackendBlacklistTest.java 与 SimpleSchedulerTest.java源码注释中也注明HostBlacklist的单元测试均位于SimpleSchedulerTest。其中BackendBlacklistTest覆盖了SHOW BACKEND BLACKLIST、ADD/DELETE BACKEND BLACKLIST等语句的解析与执行路径可以作为理解该功能行为的参考用例。相关 SQL 语句黑名单功能是一组配套语句SHOW语句通常与以下语句配合使用ADD BACKEND/COMPUTE NODE BLACKLIST手动将 BE/CN 节点加入黑名单DELETE BACKEND/COMPUTE NODE BLACKLIST手动将 BE/CN 节点移出黑名单SHOW BACKENDS获取 BE 节点列表与 BE IDSHOW COMPUTE NODES获取 CN 节点列表与 CN ID典型排障流程示例-- 1. 查看当前黑名单中有哪些节点 SHOW BACKEND BLACKLIST; -- 2. 对 AUTO 类型且 LostConnectionNumberInPeriod 持续增长的节点进一步确认其网络状态 -- 结合 SHOW BACKENDS 检查该节点的 IP、端口与心跳信息 SHOW BACKENDS\G -- 3. 若节点网络已恢复但故障期间反复断连次数超过阈值可手动确认后将其移出黑名单 -- DELETE BACKEND BLACKLIST BackendId;小结SHOW BACKEND/COMPUTE NODE BLACKLIST是查看 StarRocks BE/CN 黑名单状态的唯一入口。通过它你可以区分节点是被管理员手动拉黑MANUAL还是被系统自动拉黑AUTO观察断连次数与检查周期从而判断集群中是否存在持续失联的节点。结合 FE 配置项black_host_history_sec、black_host_connect_failures_within_time与black_host_penalty_min_ms可以按业务容忍度调整自动恢复节奏而背后的 HostBlacklist.java 实现则保证了“手动拉黑优先、自动恢复仅针对 AUTO 节点、节点下线自动清理”等关键语义为集群在高可用场景下的查询稳定性提供了保障。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考