Doris 报错及解决方案收集

保持时刻反思与复盘
13 阅读2分钟

一、doris 单节点的be报错误，启动不了了

fail to load tablet because can not parse meta_binary string. tablet_id=11826, schema_hash=142181370, path=/data/doris-2.1.5/be/storage, status=[E-206]parse tablet meta failed     data_dir.cpp:469] load tablets from header failed, loaded tablet: 990, error tablet: 1, path: /data/doris-2.1.5/be/storage load tablets encounter failure. stop BE process. path: /data/doris-2.1.5/be/storage

说明 Doris BE 在启动时无法解析某个 Tablet 的元数据文件（meta_binary），导致加载失败并强制退出。这是比较严重的元数据损坏问题。

解决方案 方案一：尝试修复损坏的 Tablet 元数据文件（推荐先尝试）

  1. 找到损坏的 Tablet 目录 cd ./doris-2.1.5/be/storage

查找 tablet_id=11826 的目录

find . -name "11826" cd ./data/xx/11826/142181370 ls -la *.hdr

  1. 备份并尝试删除 .hdr 文件（让 BE 重建）

备份整个 tablet 目录

cp -r /data/doris-2.1.5/be/storage/data/xx/11826 /tmp/11826_backup rm -f *.hdr ./bin/start_be.sh --daemon

方案二：如果是单节点测试环境，可清空数据重新开始（快速恢复）

停止 BE（如果还能 stop）

./bin/stop_be.sh

删除 storage 目录（清空所有数据）

rm -rf /data/doris-2.1.5/be/storage/*

重新启动

./bin/start_be.sh --daemon

优点：快速解决。 缺点：所有数据丢失。

方案三：从 FE 元数据恢复（适用于多副本或有元数据备份）

Doris 的 Tablet 元数据主要由 FE 管理，BE 只是本地缓存。如果 FE 正常，BE 可以通过元数据同步恢复。

但当前问题是 BE 启动失败，无法加入集群。

临时方案：修改 BE 启动参数跳过损坏 Tablet（不推荐生产使用）

跳过加载失败的 tablet（实验性，慎用）

tablet_meta_check_interval_seconds = 0

或尝试忽略错误（无直接参数，需改代码）

方案四：使用 doris-tools 或手动导出元数据（高级）

如果 .hdr 文件还能部分读取，可以尝试用 doris-inspect 工具（非官方）或调试模式读取。

但一般用户不建议，风险高。

1. 停止 BE

./bin/stop_be.sh

2. 备份整个 storage 目录

cp -r /data/doris-2.1.5/be/storage /tmp/doris_storage_backup_$(date +%F)

3. 查找损坏的 tablet 目录

find /data/doris-2.1.5/be/storage -name "11826" -type d

4. 进入目录并删除 .hdr 文件

cd /data/doris-2.1.5/be/storage/data/xx/11826/142181370 rm -f *.hdr

5. 启动 BE

./bin/start_be.sh --daemon

6. 查看日志是否成功

tail -f /data/doris-2.1.5/be/log/be.INFO | grep "tablet"

二、Doris导入数据报 current running txns on db 11666 is 1000, larger than limit 1000

表示：当前数据库 11666 上正在运行的事务（transactions）数量已经达到 1000，超过了系统默认的最大限制 1000，因此新的导入任务被拒绝。

方案一：清理已完成但未超时的“悬挂”事务（推荐）

SHOW PROC '/databases/11666/transactions';

  1. 取消长时间未完成的事务

CANCEL LOAD FOR db1 WHERE LABEL = "load2";

-- 查看所有导入任务的 Label SHOW LOAD FROM db1 WHERE LABEL LIKE "xxx";

-- 取消某个卡住的任务 CANCEL LOAD FOR db1 WHERE LABEL = "your_stuck_label";

方案二：调整事务超时时间（预防堆积）

修改 FE 配置，缩短事务超时时间，避免事务长期堆积。

  1. 修改 fe.conf

默认 600 秒（10分钟），建议改为 300 或更短

load_default_timeout_second = 300

对于不同导入方式，也可单独设置

stream_load_default_timeout_second = 300

routine_load_default_timeout_second = 600

  1. 重启 FE 生效

方案三：临时调大事务上限（应急）

如果确实需要支持更多并发事务，可以调大限制。

  1. 修改 FE 配置 fe.conf

默认 1000，可改为 2000 或更高

max_running_txn_num_per_db = 2000

  1. 重启 FE

./bin/stop_fe.sh ./bin/start_fe.sh --daemon

方案四：优化导入频率（根本解决）

避免高频小批量导入（如每秒一次 Stream Load）。 改为： 批量导入（攒批到 MB 级再导入） 使用 Routine Load 自动管理并发 使用 Broker Load 异步导入

三、批量插入数据到Doris表时报 Reason: no partition for this tuple. tuple=

这个错误的意思是：你尝试插入的数据行，其分区列的值无法匹配到任何已定义的分区（Partition），因此被拒绝。

Doris 表如果使用了 分区表（Partitioned Table），数据写入时会根据 分区列的值 路由到对应的分区。

如果你插入的一行数据，其分区列的值 不在任何现有分区的范围内（RANGE）或列表中（LIST），就会报这个错误。

常见场景： RANGE 分区：插入的时间是 2025-01-01，但最新分区只到 2024-12-31 LIST 分区：插入的地区是 Europe，但分区只定义了 America, Asia 动态分区未开启：没有自动创建新分区的机制 分区列类型不匹配：如分区列是 DATE，但插入的是 STRING 且格式错误

方案一：检查表的分区定义

SHOW CREATE TABLE your_table_name;

查看输出中的 PARTITION BY 部分，例如：

PARTITION BY RANGE(dt) (     PARTITION p202401 VALUES LESS THAN ("2024-02-01"),     PARTITION p202402 VALUES LESS THAN ("2024-03-01"),     ...     PARTITION p202412 VALUES LESS THAN ("2025-01-01") ) 说明：只支持 dt < '2025-01-01'，如果你插入 dt = '2025-01-01'，就会报错。

方案二：手动添加新分区（推荐）

根据你要插入的数据，手动创建新分区。

示例：RANGE 分区添加

ALTER TABLE your_table_name ADD PARTITION p202501 VALUES LESS THAN ("2025-02-01");

ALTER TABLE your_table_name ADD PARTITION p_europe VALUES IN ("EU", "UK", "DE", "FR");

方案三：启用动态分区（推荐用于时间分区表）

ALTER TABLE your_table_name  SET (     "dynamic_partition.enable" = "true",     "dynamic_partition.time_unit" = "DAY",     "dynamic_partition.start" = "-3",        -- 保留前3天     "dynamic_partition.end" = "3",           -- 预创建未来3天     "dynamic_partition.prefix" = "p",     "dynamic_partition.buckets" = "10" );

 方案四：检查插入数据的分区列值

 确保你插入的数据中，分区列的值是合法且在范围内。

 INSERT INTO tbl (dt, city, value) VALUES ('2025-01-01', 'Beijing', 100);

 方案五：使用 PARTITION () 显式指定分区（调试用）

 你可以用 SHOW PARTITIONS FROM your_table_name; 查看所有分区名，然后：

 INSERT INTO your_table_name PARTITION (p202501) VALUES ('2025-01-01', ...);

 如果提示分区不存在，说明你需要先 ADD PARTITION。

 四、BE报780713 status.h:412] meet error status: [NOT_FOUND]Could not find subsystem cpuacct in /proc/self/cgroup

1、​cgroup 子系统未启用​ cpuacct 子系统（用于 CPU 资源统计）未在内核中启用或未挂载到 /sys/fs/cgroup 路径 通过命令检查是否启用 cat /proc/cgroups | grep cpuacct 若输出中 enabled 列为 0，则子系统未启用。

2、​cgroup 版本冲突​ 系统可能已默认切换到 ​cgroup v2​（统一层级结构），而 cpuacct 是 cgroup v1 的子模块。v2 中 CPU 统计功能由 cgroup.controllers 统一管理，不再单独挂载 cpuacct

3、​容器化环境限制​ 若 Doris 运行在 Docker/Kubernetes 中，容器可能未挂载完整的 cgroup 子系统（如默认禁用部分功能)

解决方案

1、启用 cpuacct 子系统（cgroup v1）​​ ​挂载 cgroup v1 子系统​： sudo mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct ls /sys/fs/cgroup/cpu,cpuacct  # 确认目录存在且包含统计文件

2、 ​切换回 cgroup v1（若系统默认 v2）​ ​修改内核启动参数​： 编辑 /etc/default/grub，添加： GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0" sudo update-grub && sudo reboot cat /proc/filesystems | grep cgroup  # 输出应有 cgroup（v1）而非 cgroup2

3、容器环境特殊配置​ ​Docker 启动时挂载 cgroup​： 添加 --cgroup-parent=/sys/fs/cgroup 参数确保子系统可见： docker run -v /sys/fs/cgroup:/sys/fs/cgroup:ro ...

​Kubernetes Pod 配置​： 在 Pod YAML 中声明挂载： volumeMounts:

  • name: cgroup   mountPath: /sys/fs/cgroup   readOnly: true volumes:
  • name: cgroup   hostPath:     path: /sys/fs/cgroup

4、检查内核支持​ 确认内核编译时启用了 CONFIG_CGROUP_CPUACCT： grep CONFIG_CGROUP_CPUACCT /boot/config-$(uname -r) 若返回 CONFIG_CGROUP_CPUACCT=y 则支持，否则需升级内核或重编译。

权限问题​：确保 BE 进程用户有权访问 /sys/fs/cgroup（建议 chmod 755 /sys/fs/cgroup） ​日志定位​：检查 BE 日志 be.INFO 确认报错上下文（如是否启用了资源统计功能） ​Doris 配置​：若无需 CPU 统计，可在 be.conf 关闭相关功能： enable_cgroup_cpu_soft_limit = false

​临时测试挂载​： sudo mount -t cgroup -o cpu,cpuacct none /tmp/test_cgroup ls /tmp/test_cgroup  # 应显示 cpuacct.usage 等文件

​重启后持久生效​： 将挂载命令加入 /etc/fstab： none  /sys/fs/cgroup/cpu,cpuacct  cgroup  cpu,cpuacct  0  0

avatar
文章
阅读
粉丝