3.1.17 be crash后，出现Failed to get scan range报错。查询表报错

💬 StarRocks 用户问答
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】问题详细描述
【背景】做过哪些操作？
【业务影响】
【是否存算分离】否
【StarRocks版本】例如：3.1.17
【集群规模】例如：3fe（1leader +2follower）+6be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡，例如：64C/378G/万兆
【联系方式】邮箱lile21@xdf.cn
【附件】

  • fe.log/beINFO/相应截图
    【问题描述】：
    1、2026-02-23 18:04:00 be节点异常crash、be.out日志如下
    query_id:00000000-0000-0000-0000-000000000000, fragment_instance:00000000-0000-0000-0000-000000000000
    tracker:process consumption: 142331028816
    tracker:query_pool consumption: 13146297
    tracker:load consumption: 0
    tracker:metadata consumption: 1700685548
    tracker:tablet_metadata consumption: 127937606
    tracker:rowset_metadata consumption: 244722796
    tracker:segment_metadata consumption: 149318379
    tracker:column_metadata consumption: 1178706767
    tracker:tablet_schema consumption: 5335590
    tracker:segment_zonemap consumption: 66086833
    tracker:short_key_index consumption: 73143241
    tracker:column_zonemap_index consumption: 290748207
    tracker:ordinal_index consumption: 617964752
    tracker:bitmap_index consumption: 3200
    tracker:bloom_filter_index consumption: 0
    tracker:compaction consumption: 873767096
    tracker:schema_change consumption: 0
    tracker:column_pool consumption: 5624872535
    tracker:page_cache consumption: 43153753232
    tracker:update consumption: 75652500215
    tracker:chunk_allocator consumption: 2148531232
    tracker:clone consumption: 0
    tracker:consistency consumption: 0
    tracker:datacache consumption: 0
    tracker:replication consumption: 0
    *** Aborted at 1771841184 (unix time) try “date -d @1771841184” if you are using GNU date ***
    PC: @ 0x337ba04 starrocks::ZoneMapPB::~ZoneMapPB()
    *** SIGSEGV (@0x55717) received by PID 195497 (TID 0x7fdc7e9fe700) from PID 349975; stack trace: ***
    @ 0x688b642 google::(anonymous namespace)::FailureSignalHandler()
    @ 0x7fdfff2125f0 (unknown)
    @ 0x337ba04 starrocks::ZoneMapPB::~ZoneMapPB()
    @ 0x572b713 starrocks::ColumnReader::~ColumnReader()
    @ 0x526d299 starrocks::Segment::~Segment()
    @ 0x598790a starrocks::Rowset::do_close()
    @ 0x517fcb1 starrocks::Rowset::close()
    @ 0x5228f6f starrocks::TabletUpdates::_do_compaction()
    @ 0x522ad2c starrocks::TabletUpdates::compaction_for_size_tiered()
    @ 0x522b7ea starrocks::TabletUpdates::compaction()
    @ 0x516c70b starrocks::StorageEngine::_perform_update_compaction()
    @ 0x50fe7e4 starrocks::StorageEngine::_update_compaction_thread_callback()
    @ 0x8cca900 execute_native_thread_routine
    @ 0x7fdfff20ae65 start_thread
    @ 0x7fdffe60c88d __clone
    @ 0x0 (unknown)

2、手动恢复节点后，有4个flink实时写入表报错
fe日志报错：
Caused by: com.starrocks.common.UserException: Failed to get scan range, no queryable replica found in tablet=551194599 replica=10003:2439/-1/2439/2424:NORMAL:ALIVE,10004:2439/-1/2439/2424:NORMAL:ALIVE,10002:2439/-1/2439/2424:NORMAL:ALIVE, schema_hash=261007876 version=2299
查询返回报错：
Build Exec OlapScanNode fail, scan info is invalid

3、ADMIN SHOW REPLICA STATUS FROM table;发现version_error的tablet，使用如下命令set bad
ADMIN SET REPLICA STATUS PROPERTIES(“tablet_id” = “”, “backend_id” = “”, “status” = “bad”);

image
image1413×432 62.8 KB

4、操作后，表仍然无法访问，查询日志报错
Caused by: com.starrocks.common.UserException: Failed to get scan range, no queryable replica found in tablet=551194599 replica=10003:2439/-1/2439/2424:NORMAL:ALIVE,10004:2439/-1/2439/2424:NORMAL:ALIVE,10002:2439/-1/2439/2424:NORMAL:ALIVE, schema_hash=261007876 version=2299

显示报错的tablet 状态是ok的，但version、LastSuccessVersion比CommittedVersion大很多；想了解下产生问题的原因，以及如何解决？

show partitions from table where partitionname=’’;
ADMIN SHOW REPLICA STATUS FROM table;

image
image1392×447 29 KB

image
image1047×360 16.4 KB

#2

这个错误信息和 BE 崩溃堆栈跟踪表明您的 StarRocks 集群遇到了一个严重的数据一致性问题，导致 BE 崩溃，随后查询失败并报告 Failed to get scan range, no queryable replica found。

问题原因分析：

  1. BE 崩溃 (ZoneMapPB::~ZoneMapPB()): 崩溃发生在 starrocks::ZoneMapPB::~ZoneMapPB()，这通常与 ZoneMapPB 对象的销毁过程有关，而 ZoneMapPB 是用于存储列的最小/最大值索引（zonemap）的协议缓冲区对象。堆栈跟踪显示这个崩溃发生在 ColumnReader、Segment、Rowset 的析构过程中，并且是在 TabletUpdates::_do_compaction() 的上下文中。这强烈暗示在 BE 节点进行数据合并（compaction）或处理 Segment/Rowset 元数据时，发生了内存损坏、无效指针访问或其他底层数据结构问题，导致了 BE 崩溃。
  2. Failed to get scan range, no queryable replica found: BE 崩溃后，一些 tablet 的副本可能处于不一致状态。当 FE 尝试为查询查找可用的 tablet 副本时，发现所有副本都不可用（可能是因为它们报告了 version_error，或者内部状态不健康），因此无法构建扫描计划。
  3. version_error 和 version 远大于 CommittedVersion: 这是问题的核心。
    • CommittedVersion 是一个 tablet 在整个集群中所有必需副本都成功提交并可见的最高版本。
    • version 是单个副本的本地版本。
    • LastSuccessVersion 是该副本最后一次成功应用数据更新的版本。
      当 version 远大于 CommittedVersion 并且出现 version_error 时，这意味着该副本可能接收并处理了一些数据更新，但这些更新未能成功地在集群层面提交，或者由于 BE 崩溃导致其内部元数据损坏，使其处于一个不一致的中间状态。FE 认为这些副本是不可信的，因此无法用于查询。

总结： BE 崩溃可能在 compaction 或数据写入过程中破坏了部分 tablet 副本的元数据，导致它们处于 version_error 状态且版本号异常。由于所有副本都不可查询，FE 无法为查询找到健康的副本。

解决方案：

为了解决 Failed to get scan range 和 version_error 的问题，您需要强制 StarRocks 重新同步或重建这些不健康的 tablet 副本。您尝试的 ADMIN SET REPLICA STATUS PROPERTIES(“tablet_id” = “”, “backend_id” = “”, “status” = “bad”); 是正确的方向，但需要确保对所有不健康的副本都执行此操作，以触发全面的恢复。

请按照以下步骤操作：

  1. 再次确认所有受影响的 Tablet 及副本状态：

    ADMIN SHOW REPLICA STATUS FROM <table_name>;

    仔细检查所有 version_error 的 tablet，以及那些 version 远大于 CommittedVersion 的副本。记下这些 tablet 的 TabletId 和它们所在的 BackendId。

  2. 将所有不健康的副本标记为 BAD：
    对于每一个在步骤 1 中发现的、处于 version_error 状态或版本异常的 tablet，您需要将其所有副本（在不同的 Backend 上）都标记为 BAD。这将强制 StarRocks 认为这些副本不可用，并触发其自动恢复机制，通常是重新克隆（clone）一个健康的副本。

    -- 对每一个不健康的 tablet 和其对应的 backend 执行此命令
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "<tablet_id>", "backend_id" = "<backend_id>", "status" = "bad");

    示例： 如果 tablet 551194599 在 BE 10003, BE 10004, BE 10002 上都有副本且都报告问题，您需要执行三次：

    ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "551194599", "backend_id" = "10003", "status" = "bad");
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "551194599", "backend_id" = "10004", "status" = "bad");
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "551194599", "backend_id" = "10002", "status" = "bad");

  3. 监控 Tablet 恢复进度：
    执行上述操作后，StarRocks 会自动尝试修复这些 BAD 副本。您可以通过以下命令持续监控恢复状态：

    ADMIN SHOW REPLICA STATUS FROM <table_name>;
SHOW PROC '/dbs/<db_id>/<table_id>/partitions/'; -- 查看分区和 tablet 的总体健康状况

    观察 ADMIN SHOW REPLICA STATUS 的输出，等待 Status 变为 NORMAL，并且 version、LastSuccessVersion 和 CommittedVersion 趋于一致。这个过程可能需要一些时间，具体取决于数据量和集群负载。

  4. 检查 FE 和 BE 日志：
    在恢复过程中，密切关注 FE 和 BE 的日志。FE 日志会显示副本调度和克隆的信息，BE 日志会显示实际的数据克隆和写入情况。如果恢复卡住或出现新的错误，日志将提供重要的线索。

  5. 数据写入恢复：
    一旦所有受影响的 tablet 副本都恢复到 NORMAL 状态且版本一致，您的 Flink 实时写入和查询应该能够正常进行。

重要提示：

  • 数据丢失风险： 如果某个 tablet 的所有副本都处于 version_error 状态且无法通过克隆从其他健康副本恢复（例如，所有副本都已损坏且无任何一致的历史版本可供恢复），则存在该 tablet 数据丢失的风险。在这种情况下，可能需要从备份中恢复数据，或者重新导入数据。
  • 根因调查： 解决当前查询问题后，强烈建议您深入调查 BE 崩溃的根本原因 (ZoneMapPB::~ZoneMapPB())。这可能涉及检查 BE 服务器的硬件健康状况（内存、磁盘）、操作系统日志，以及 StarRocks 的详细 BE 日志，看是否有更具体的错误信息或异常模式。这个问题可能指向一个更深层次的 Bug 或环境问题。

京ICP备2022026421号-1