部分fe节点查询报错failed to get tablet. tablet_id=328595869, with schema_hash=424008707, reason=tablet does not exist backend [id=10065]...

zxb2503 · 2025年11月17日 08:19

【详述】同一个查询5个fe其中有一个fe会报错,报错信息如下:

select count(*) from ods_xzf_t_mpos_trade_water where create_time>=‘2025-08-01 00:00:00’;
ERROR 1064 (HY000): failed to get tablet. tablet_id=328595869, with schema_hash=424008707, reason=tablet does not exist backend [id=10065] [host=10.168.88.14]

其他4个fe执行查询均正常,尝试重启该fe,和清空meta目录,重新启动start_fe.sh --helper 10.168.xx.xx:9010 --daemon 还都是报错

在查询报错的fe上查看副本状态,多了一条versioncount=-1的记录,对应的be都是10.168.88.14

【背景】
1.10.168.88.14 这个be报错前做过停机维护,启动的时候报错,启动不了be

应急将/data/srdb/storage/disk8从be.conf去掉启动了be,过了一天在社区群里咨询可以加ignore_load_tablet_failure =true 参数启动,又加了这个参数重启了be

2.原来是3个fe与be混布,目前想要进行fe与be剥离,又新增了两个fe

【业务影响】路由到该fe的查询报错
【是否存算分离】否
【StarRocks版本】3.2.8
【集群规模】5fe（5 follower）+12be（fe与be混部）
【机器信息】40C/256G/万兆
【联系方式】 StarRocks社区群5 -思变 [1412195108@qq.com]

JohnsonMeng · 2025年11月18日 02:57

这是一个非常典型的 StarRocks FE 元数据不一致的问题，通常发生在集群拓扑结构发生变化（如您提到的 FE/BE 剥离、新增 FE）或 BE 节点出现故障时。

问题诊断：FE 元数据不一致

核心现象：

一个 FE 报错，其他 FE 正常。
报错信息： failed to get tablet. tablet_id=328595869, with schema_hash=424008707, reason=tablet does not exist backend [id=10065] [host=10.168.88.14]
问题 FE 上的副本状态： 存在一条 versioncount=-1 的记录，指向 BE 10.168.88.14。

分析：

FE 元数据同步机制： StarRocks 的 FE 节点通过 Raft 协议保持元数据一致性。Leader FE 负责写入，Follower FE 从 Leader 同步。
Tablet 不存在： 报错 FE 认为 tablet_id=328595869 应该存在于 BE 10.168.88.14 上，但当它尝试查询时，BE 告诉它“这个 Tablet 不存在”。
versioncount=-1： 这通常是 BE 节点在报告 Tablet 状态时，由于某些原因（如磁盘故障、数据损坏、Tablet 被删除但元数据未及时清理）无法提供正确的版本信息时出现的异常状态。
FE 剥离/新增 FE 导致的问题： 在集群拓扑变化时，如果新的 FE 节点在同步元数据时，恰好 BE 节点 10.168.88.14 上的这个 Tablet 处于异常状态，或者在同步过程中发生了 Leader 切换，可能导致这个新的 FE 节点（或同步失败的 FE 节点）的元数据中，关于这个 Tablet 的信息是错误的或过时的。

结论： 报错的 FE 节点上的元数据中，关于 Tablet 328595869 的信息是错误的，它错误地认为 BE 10.168.88.14 上存在一个可用的副本，而其他 FE 节点可能已经通过正常的健康检查机制，将该副本标记为不可用或已删除。

应急处理和后续影响分析

1. 应急操作分析

重启 FE 并用 --helper 启动： 这是一个正确的尝试，目的是让 FE 重新从 Leader FE 同步完整的元数据。但如果 Leader FE 上的元数据本身存在一些“脏数据”或同步机制在特定情况下失败，可能无法解决问题。
BE 节点操作：
- 将 /data/srdb/storage/disk8 从 be.conf 去掉： 这是一个正确的应急操作。如果 BE 上的某个磁盘（disk8）出现问题，导致其上的 Tablet 无法访问（如 versioncount=-1），将该磁盘移除可以避免 BE 尝试使用该磁盘上的损坏副本。
- 加 ignore_load_tablet_failure = true 启动 BE： 这个参数主要用于忽略导入时遇到的 Tablet 失败，让导入继续。它有助于导入任务，但不能解决元数据不一致的问题。

2. 为什么重启和清空 Meta 仍报错？

清空 Meta 重新启动 FE，它会从 Leader FE 同步元数据。如果 Leader FE 上的元数据中，关于这个 Tablet 的信息仍然指向 BE 10.168.88.14（即使其他 FE 已经知道这个副本不可用），那么新启动的 FE 也会同步到这个错误的认知。

解决方案和建议步骤

您需要强制让 StarRocks 集群清理掉这个错误的副本信息，并让所有 FE 保持一致。

步骤 1: 确认 Tablet 状态和副本情况

在任意一个正常工作的 FE 节点上执行以下命令，确认 Tablet 的实际状态：

-- 查找该 Tablet 属于哪个表和分区
SELECT * FROM information_schema.tablets WHERE tablet_id = 328595869;

-- 查找该 Tablet 的所有副本状态
ADMIN SHOW REPLICAS FROM 328595869;

预期结果： 正常 FE 应该显示该 Tablet 在 BE 10.168.88.14 上的副本状态是 BAD 或 MISSING，或者该副本已经被系统自动删除。

步骤 2: 强制修复元数据（如果需要）

如果确认该 Tablet 在 BE 10.168.88.14 上的副本确实是损坏或不存在的，并且系统没有自动清理，您需要手动干预：

检查 BE 状态： 确保 BE 10.168.88.14 已经稳定运行，并且其有问题的磁盘（disk8）已经永久移除或修复。
强制删除损坏副本（谨慎操作）：
```
-- 假设 BE ID 是 10065
ADMIN FORCEREPAIR TABLET 328595869 ON (10065);
```
注意： 只有在您确定该 Tablet 还有足够的健康副本（例如，副本数为 3，还有 2 个健康副本）时才能执行此操作。此命令会通知 Leader FE 永久删除该 BE 上的副本元数据。

步骤 3: 强制同步 FE 元数据

在执行完修复操作后，或者确认 Leader FE 上的元数据已经正确后，对报错的 FE 节点进行强制同步：

找到 Leader FE： 在任意 FE 上执行 SHOW FRONTENDS; 找到 Leader FE。
在报错 FE 上执行：
```
-- 尝试重新同步元数据
ADMIN SYNC REPLICA META;
```
如果问题 FE 仍然无法通过正常同步解决，最彻底的方法是：
- 停止该 FE。
- 彻底删除其 meta 目录下的所有内容（您已经尝试过）。
- 使用 --helper 重新启动，确保它能从 Leader FE 完整同步。

如果清空 Meta 重新启动后仍然报错，这强烈暗示 Leader FE 上的元数据本身存在问题，或者 BE 10.168.88.14 仍在向 FE 报告错误的状态。 此时，您需要检查 Leader FE 的 fe.log，看是否有关于 Tablet 328595869 的错误或警告信息。

关于 FE/BE 剥离的建议

您新增 FE 并进行剥离是正确的架构方向。在进行拓扑结构调整时，元数据同步和健康检查是关键。在剥离完成后，请确保所有 FE 节点都处于 Follower 或 Leader 状态，并且 IsMaster 状态一致。

部分fe节点查询 报错failed to get tablet. tablet_id=328595869, with schema_hash=424008707, reason=tablet does not exist backend [id=10065]...