obsidian-sync/问题排查/doris/Failed to get scan range, no queryable replica found in tablet (副本之间版本号不一致).md

当您查询表 ods_ms_crjry 时，Doris 需要读取一个或多个数据分片（Tablet）。对于其中一个 ID 为 1173992 的分片，Doris 找不到任何一个“健康且版本最新”的副本（Replica）来执行查询。 Tablet 1173992 的所有副本都因为版本落后或损坏，无法满足查询所需的数据版本要求，导致查询失败。

一、原因

1. 数据导入失败：最常见的原因。一个导入任务（如 Stream Load, Broker Load）在执行过程中部分失败。FE（Frontend）已经将元数据中的目标版本更新了，但某些 BE（Backend）节点上的副本未能成功应用这次数据变更。
2. BE 节点问题：某个 BE 节点可能存在磁盘问题、网络问题或进程异常，导致它无法完成数据同步或 Compaction（数据合并）任务。尽管 backendAlive=true 表示心跳正常，但它可能无法正常工作。
3. Compaction 失败：后台的数据合并任务失败，也可能导致副本版本不一致。
4. Schema Change 失败：执行 ALTER TABLE 操作失败，也可能使表处于不一致的状态。

二、解决方案

1. 查看副本状态

首先，使用管理员命令查看这个表所有副本的状态，重点关注那些状态不是 OK 的副本。

ADMIN SHOW REPLICA STATUS FROM ods_ms_crjry WHERE STATUS != 'OK';

执行这个命令，你会看到所有有问题的副本列表。重点关注 Status 列，它可能会显示 VERSION_ERROR、SCHEMA_ERROR 或其他错误状态，这能直接告诉你问题所在。

2. 检查 BE 节点日志

根据上一步找到的有问题的副本所在的 BackendId，去对应的 BE 节点的日志目录（通常是 be/log/）下查找线索。

• 日志文件: be.WARNING 或 be.out。
• 搜索关键词: 使用 grep 命令搜索出问题的 Tablet ID 1173992 和 失败的版本号 325968 日志中通常会记录失败的具体原因，例如 "disk is full", "file not found", "data quality error" 等。

3. 尝试手动修复副本

如果确定某个副本确实损坏了，并且确保该 Tablet 还有其他健康的副本，你可以尝试手动将这个损坏的副本设置为 bad。

-- 假设 backendId=116608 上的副本有问题
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "1173992", "backend_id" = "116608", "status" = "bad");

执行后，Doris 的后台修复机制会检测到这个坏副本，并尝试从一个健康的副本克隆一个新的副本过来，以恢复副本数。 注意： 如果一个 Tablet 的所有副本都损坏了，这个方法将无效，并且可能会导致数据丢失。

4.如果以上方法都无法解决，或者所有副本都已损坏，最可靠的方法是：

1. 删除有问题的数据：如果表是分区的，可以考虑只删除有问题的分区。如果无法定位到具体分区，可能需要删除整张表（就像你编辑器里写的那样 drop table ods_ms_crjry;）。
2. 重新导入数据：从你的数据源重新导入这部分数据。

如果连 DROP TABLE 都失败，可以尝试强制删除：DROP TABLE ods_ms_crjry FORCE;