王工的 Doris 查询异常小记

数据微光 2025-01-10

134

更多精彩内容请关注数据微光

王工在最近的一次 Doris 查询中，遇到了一个令他困扰的报错信息：

[CANCELLED]failed to initialize storage reader. tablet=12034214, res=[IO_ERROR]failed to read /data/doris/be/data/921/12034214/1235723928/020000000028650c634b5b9e40d26aef437bfbc32c0277a6_1.dat, backend=10.100.2.124')

机缘巧合下，链接到向光，经过初步定位：

该报错信息指出在初始化存储读取器时失败，具体原因是无法读取某个数据文件。

以下是对此次报错排查过程的详细记录。

步骤一：初步诊断

首先我们排查一下 tablet 是否有问题，这里可以参考上一篇的数据副本排查指南

查看 Tablet 状态：

使用show tablet 12034214
命令查看 Tablet 的详细信息。
执行detail cmd
的内容，确认 Tablet 的 version 状态正常。

检查文件权限：

tablet 状态都是正常的，于是我们确认一下报错对应的文件权限是否正常

步骤二：文件校验与损坏确认

既然 Doris 拥有读取文件的权限，那么问题是否出在文件本身呢？为了验证这一点，我们使用sha1sum
命令尝试计算文件的哈希值。

下图使用sha1sum
命令尝试计算文件的哈希值，但操作失败，说明我们已经找到问题的关键了，这表明文件已损坏，无法读取，可能的原因包括磁盘故障或 Compaction 过程中出现问题。

步骤三：验证其他副本

由于该表采用了三副本策略，所以我们来看看其他副本是否也损坏了呢？

通过set use_fix_replica=0, 1, 2
分别查询对应的 Tablet 数据，发现可以正常查询到数据，说明其他副本是正常的。

-- 查看某个 tablet 的数据
select * from db.table tablet(tablet_id)

由此确定，只需删除损坏的副本即可，Doris 会自动从其他正常副本 clone 一个新的副本。

use_fix_replica使用固定 replica 进行查询。replica 从 0 开始，如果 use_fix_replica 为 0，则使用最小的，如果 use_fix_replica 为 1，则使用第二个最小的，依此类推。默认值为 -1，表示未启用。

步骤四：尝试修复

避免直接删除文件：直接删除.dat
文件可能会引起未知错误。
使用官方推荐方法：
这是什么原因呢？通过查阅官方文档，我们发现设置为 Bad 状态的副本，如果副本状态实际上是正常的（尽管文件已损坏），FE 会自动将其恢复为 ok 状态。这解释了为什么设置 bad 状态无效的原因。

在之前的数据副本修复指南中提到，可以使用ADMIN SET REPLICA STATUS PROPERTIES
命令来自动修复副本。
我们尝试将副本状态设置为bad
，但发现设置后很快被 FE 自动恢复为ok
状态，并且 clone 副本也消失了。

步骤五：正确设置副本状态为`drop`

同时我们通过官方文档知道设置为Drop
状态的副本，仍然可以读写，但会在其他机器上先增加一个健康副本，再删除该副本。这个就非常符合我们当前的场景。

使用以下命令设置副本状态为drop
：
```
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "12034214", "backend_id" = "9697584", "status" = "drop");
```
（注意：将tablet_id
和backend_id
替换为实际的 tabletId 和 Backend ID，通过 show backends 可以找到 BackendID 和 be 实际 IP 之间的对应关系）
其他正常的 BE 会 clone 一个新的副本，然后删除该 BE 上的损坏副本，从而恢复正常读写。