---
title: 排查 OceanBase 数据库 V4.x 版本中日志问题-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 排查 OceanBase 数据库 V4.x 版本中日志问题相关的常见问题和使用技巧，帮助您快速解决 排查 OceanBase 数据库 V4.x 版本中日志问题的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 排查 OceanBase 数据库 V4.x 版本中日志问题

更新时间：2025-10-13 02:26

适用版本： V4.0.x、V4.1.x、V4.2.x 内容类型：TechNote  

当出现日志模块相关问题时，可以先查询 `__all_virtual_ha_diagnose` 观察当前日志各个模块的状态。

此表的意义在于省去问题排查的一些中间步骤，快速找到问题产生模块。目前此表支持快速定位无主，回放卡住，盘爆的问题。

有关内部表 `__all_virtual_ha_diagnose` 的详细信息如下：

| 列名 | 备注 |
| --- | --- |
| SVR_IP | IP 地址 |
| SVR_PORT | 端口号 |
| TENANT_ID | 租户 ID |
| LS_ID | 日志流 ID |
| ELECTION_ROLE | 选举层角色 |
| ELECTION_EPOCH | 选举 epoch |
| PALF_ROLE | palf 层角色 |
| PALF_STATE | palf 状态 |
| PALF_PROPOSAL_ID | palf 层 proposal id |
| LOG_HANDLER_ROLE | log handler 层角色 |
| LOG_HANDLER_PROPOSAL_ID | log handler 层 proposal id |
| LOG_HANDLER_TAKEOVER_STATE | log handler 切主状态 |
| LOG_HANDLER_TAKEOVER_LOG_TYPE | log handler 当前切主模块 |
| MAX_APPLIED_SCN | 最大连续回调 scn |
| MAX_REPALYED_LSN | 最大连续回放 lsn |
| MAX_REPLAYED_SCN | 最大连续回放 scn |
| REPLAY_DIAGNOSE_INFO | 回放诊断信息 |
| GC_STATE | gc 当前状态 |
| GC_START_TS | gc 开始时间 |
| ARCHIVE_SCN | 归档位点 |
| CHECKPOINT_SCN | checkpoint 位点 |
| MIN_REC_SCN | 最小 rec log ts |
| MIN_REC_SCN_LOG_TYPE | 贡献最小 rec log ts 的模块 |
| RESTORE_HANDLER_ROLE | restore handler 角色 |
| RESTORE_PROPOSAL_ID | restore 层 proposal id |
| RESTORE_CONTEXT_INFO | |
| RESTORE_ERR_CONTEXT_INFO | |
| ENABLE_SYNC | 日志同步是否开启 |
| ENABLE_VOTE | 是否允许投票 |
| ARB_SRV_INFO | |

## 日志常见问题排查步骤

### 无主

根据 tenant_id 和 ls_id 找到副本对应的行，自底向上以此观察选举，palf，log handler 的角色状态：

- 所有副本的 `election_role` 均为 follower，说明选举层无法选出新主。此场景常见的问题为消息延迟过大，可以继续在日志中排查消息延迟或积压的问题。
 - 某个副本的 `election_role` 为 leader，但 `palf_role`、`palf_state` 分别不为 leader、active，说明选举选出的新 leader 在 palf 层上任失败，通过 `palf_state` 可以明确 palf 上任失败的具体位置，可联系技术支持人员进一步排查。
 - 某个副本的 `election_role` 和 palf_role 均为 leader，但 log_handler_role 为 follower，说明 log_handler 层上任失败，此场景下继续根据 `log_handler_takeover_state` 的值分析：
     - `wait_replay_done`：上任过程中等待日志回放完成。此时，应跳转至回放问题排查部分。
     - `unknown`：role change service 尚未调度到此任务。检查相应租户的其余日志流，找出也有 log handler 上任失败问题的日志流，然后根据 `log_handler_takeover_state` 不为 unknown 的日志流继续排查。
     - `wait_rc_handler_done`：判断上任过程中卡在哪个模块。`log_handler_takeover_log_type` 的结果中打印的模块即为上任卡住的模块。针对该模块，可联系技术支持人员，排查模块在 switch_to_leader 过程中卡住的原因。

### 回放卡住

当怀疑回放存在问题时，可以通过观察虚拟表 `__all_virtual_ha_diagnose` 中的 `max_replayed_lsn` 列来判断。如果 `max_replayed_lsn` 长时间没有变化，可能表明回放过程出现了卡顿。

如果 `max_replayed_lsn` 在变化，说明回放过程正在进行，可参考 [排查 OceanBase 数据库 V4.0 版本中 ReplayService 问题](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000787744) 进行排查。

如果 `max_replayed_lsn` 卡住不变，应观察 `replay_diagnose_info` 列中的信息，该列记录了当前回放任务中风险最高的日志的诊断信息。

`replay_diagnose_info` 列包含几个关键指标：

- ret：表示此日志回放的错误码，可联系技术支持人员进行排查。
 - min_unreplayed_lsn：此项表示未回放日志的 LSN。
 - min_unreplayed_scn：此项表示未回放日志的 SCN。
 - replay_hint：表示事务 ID。
 - log_type：表示日志的类型。
 - replay_cost：表示此任务回放的耗时，仅在回放成功时进行统计。
 - retry_cost：表示任务重试的耗时，从首次回放报告错误码 4023 开始计算。
 - first_handle_time：表示此任务首次被回放的时间戳。

### 日志盘满

若遭遇日志盘满，可按照以下步骤进行排查：

1. 确认是否与回放卡住问题相关，先进行回放问题排查。
 2. 确认回放无关后，排查哪个模块的 rec_log_ts 阻碍了日志回收，MIN_REC_SCN_LOG_TYPE 列可显示目前 rec_log_ts 最小模块。
 3. 参考 [Clog 盘满如何排查](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000817377)，找到并解决导致盘满的问题源。

## 适用版本

OceanBase 数据库 V4.x 版本。

Previous

[NFS 写坏文件导致告警 checksum is not consistent 的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002398337)

Next

[挂载对象存储目录，对象存储报错 -4103(OB_CHECKSUM_ERROR) 的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003029175) ![有帮助](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) 咨询热线