---
title: OBServer 进程在重启后扫描 ilog 盘报错导致 fatal error 进程自动退出-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于OBServer 进程在重启后扫描 ilog 盘报错导致 fatal error 进程自动退出相关的常见问题和使用技巧，帮助您快速解决OBServer 进程在重启后扫描 ilog 盘报错导致 fatal error 进程自动退出的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# OBServer 进程在重启后扫描 ilog 盘报错导致 fatal error 进程自动退出

更新时间：2026-06-08 02:36

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 适用版本

OceanBase 数据库 V2.x、V3.x 版本。

## 问题描述

该问题常见于两个场景：

- OceanBase 数据库升级。
 - observer 进程意外退出。

此问题发生后，启动 observer 进程失败，重试结果相同。进程退出没有 core dump 产生而是自动退出。

在 `observer.log` 日志中可以搜索关键词 `on_fatal_error`。

```shell
[2021-11-05 17:50:07.860557] ERROR [CLOG] notify_scan_finished_ (ob_log_scan_runnable.cpp:668) [94552][2114][Y0-0000000000000000] [lt=7] [dc=0] invalid scan_confirmed_log_cnt(ret=-4016, ret="OB_ERR_UNEXPECTED", scan_confirmed_log_cnt=0, next_ilog_id=145, last_replay_log_id=133, pkey={tid:1101710651090796, partition_id:8, part_cnt:0}) BACKTRACE:0xd46316a 0x34a8572 0x7a69769 0x7a69f77 0x7a6a3bf 0x7a6a6da 0x7a76cac 0x6046fea 0x3bb7ecc 0xd216507 0xd214260 0xd21201f
[2021-11-05 17:50:07.861475] ERROR [CLOG] do_scan_log_ (ob_log_scan_runnable.cpp:222) [94552][2114][Y0-0000000000000000] [lt=16] [dc=0] notify_scan_finished_ failed(ret=-4016) BACKTRACE:0xd46316a 0x34a8572 0x3501d2a 0x3502335 0x7a65498 0x7a76e68 0x6046fea 0x3bb7ecc 0xd216507 0xd214260 0xd21201f
[2021-11-05 17:50:07.861505] ERROR [CLOG] do_scan_log_ (ob_log_scan_runnable.cpp:229) [94552][2114][Y0-0000000000000000] [lt=30] [dc=0] log scan runnable exit error(ret=-4016) BACKTRACE:0xd46316a 0x34a8572 0x3501d2a 0x3502335 0x7a6550a 0x7a76d3f 0x6046fea 0x3bb7ecc 0xd216507 0xd214260 0xd21201f
[2021-11-05 17:50:07.861793] ERROR on_fatal_error (ob_log_define.h:667) [94552][2114][Y0-0000000000000000] [lt=15] [dc=0] ret = -4016 BACKTRACE:0xd46316a 0x7561b4b 0x7a76d5c 0x6046fea 0x3bb7ecc 0xd216507 0xd214260 0xd21201f BACKTRACE:0xd46316a 0x34a8572 0xd38ae0a 0x7561b94 0x7a76d5c 0x6046fea 0x3bb7ecc 0xd216507 0xd214260 0xd21201f

```

## 问题原因

主要原因是 `file_id_cache` 读取到的 ilog 内容中涉及到的 clog 已经被回收。

举个例子：

1. 分区 A 首先写一段日志 30-100 号，ilog 和 clog 均落盘到 ilog1 和 clog1，然后分区 A 被迁走，分区 GC 时会对 clog1 做回收，但是 ilog1 却保留了下来。
 2. 此后分区 A 再次迁回这个 OBServer，并且重新写下 30-100 号日志并滑出，这时 clog2 里面记录了这批新的日志，但是对应的 ilog 并没有落盘(每 10s 落盘一次)。
 3. 此时宕机重启，分区 A 构建 `file_id_cache` 会用 ilog1，但是 clog1 已经不存在了，扫盘也会从最小的 clog2 开始。
 4. 但是这批新的 clog 日志因为和 ilog1 中记录的信息并不匹配所以会被丢弃，导致一条日志拉不到触发条数的防御性报错。

## 解决方法

通过清空 ilog 然后再次启动即可。

上一篇

[OBServer 服务器重启后 observer 进程未能自动启动](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000210133)

下一篇

[OBServer 线程主动 hung 问题](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207668) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线
