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

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

划线反馈

# 排查 OceanBase 数据库 V4.0 版本中 ReplayService 问题

更新时间：2024-05-09 11:22

适用版本： V4.0.x 内容类型：Troubleshoot  

`Replay service` 作为 Follower 回放日志主路径的调度者，在 OBServer 出现非预期问题时会作为屏障阻止后续日志的回放，以防止出现更严重的正确性问题。但是非预期的错误往往并不在 `Replay service` 自身，而是出在各个模块不同类型日志的具体回放逻辑中，本文旨在方便快速定位到出问题的源头，加快处理问题的效率。

## 常见问题 1 ：回放卡住/回放位点不推进 /pre_check 的 ERROR 报错

### 如何确认回放卡

首先需要明确回放卡的语意，回放位点小于同步位点，如果回放位点等于同步位点，则是同步本身出了问题。

可以在 SYS 系统租户下，通过以下查询确认日志流副本的同步位点（`end_scn`），已提交回放的位点（`unsubmitted_log_scn`）和在回放队列中等待回放的日志任务数（pending_task_count）。

```shell
select a.svr_ip, a.svr_port, a.tenant_id, a.ls_id, b.end_scn, a.unsubmitted_log_scn, a.pending_cnt from oceanbase.__all_virtual_replay_stat a join oceanbase.__all_virtual_log_stat b on a.svr_ip=b.svr_ip and a.svr_port=b.svr_port and a.tenant_id=b.tenant_id and a.ls_id = b.ls_id and a.role='FOLLOWER';

```

如果 `unsubmitted_log_scn` 和 `pending_task_count` 长时间不变化，同时 `unsubmitted_scn` 小于 `end_scn` 则回放卡住。

### 排查步骤

#### 排除回放线程卡

`obstack $pid -ao` 连续执行两次，查找是否有 Txxx_ReplayS 线程的堆栈没有变化。 同时用疑似卡的线程号过滤日志（`grep $thread_id observer.log`），如果线程长时间没有打印日志，则是卡住了，请联系 OceanBase 技术支持人员协助排查，有关线程卡的原因。

#### 回放报 fatal error，即不可重试的错误

排查步骤：

1. 首先确定出问题的租户（后文用 T1xxx 表示）和日志流（后文用 id:xxx 表示），查看对应日志流的回放是否遇到 `fatal error` 即不可重试的报错，这种类型的回放报错会打印 error 日志：

   ```shell
   grep 'T1xxx_ReplaySrv' observer.log | grep 'id:xxx' | grep 'ReplayService has encountered a fatal error' | grep ERROR

   ```

   输出内容如下：

   ![image001.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240428ReplayService001.png)

   此日志会重复打印，根据其中任意一条的 `err_ts_` 找到对应的报错时间（select usec_to_time(err_ts_) from dual），`err_ret_` 是回放报错的错误码。
 2. 搜索报错时间附近的 OBServer 日志找到报错的起始点，并找到对应的线程。

   ```shell
   grep 'T1xxx_Replay' observer.log.xxxx | grep 'id:xxx' | grep process_replay_ret_code_

   ```

   输出内容如下：

   ![image002.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice002.png)
 3. 根据线程找到回放报错时的详细链路堆栈信息，分析链路中错误码吐出的原因即可定位问题。

   ```shell
   grep '$thread_id]' observer.log.xxxx | vim -

   ```

   输出内容如下：

   ![image003.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice003.png)

#### 其他场景

1. 可以先查看当前日志流最小未连续回放位点相关信息。

   ```shell
   grep 'get_min_unreplayed_log_info' observer.log | grep 'T1xxx' | grep 'id:xxx'

   ```

   输出内容如下：

   ![image004.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice004.png)

   首先查看 `is_enabled` 字段是否为 true，如果为 false，则回放未启动，符合预期。 然后观察结果中的 scn，观察 scn 是否变化：

      - 如果几次的结果均不同，则可以转到 **常见问题 2：回放慢** 这一节，按照回放慢的逻辑排查。
      - 如果几次结果均相同，则表示回放位点卡住。转到步骤 2 。
 2. 需要继续日志确认卡的原因。

   ```shell
   grep "submit replay task need retry" observer.log | grep "Txxx_" | grep "id:xxxx"

   ```

   输出内容如下：

   ![image005.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice005.png)

      - 其中 `is_tenant_out_of_mem=true` 表明 MEMStore 没有内存导致，请联系 OceanBase 技术支持人员协助排查，确认 MEMStore 内存爆的原因。
      - `is_wait_for_barrier` 表明当前在等 `barrier` 日志回放。

   通过 `grep 'T1xxx_ReplaySrv' observer.log | grep 'id:xxx' | grep WDIAG` 可以看到回放报错的日志。再根据线程号找到报错的上下文。 此外也可以用下图中的 scn 来过滤对应日志流的回放日志：

   ![image006.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice006.png)

   另外通过 `grep 'T1xxx_ReplaySrv' observer.log | grep 'id:xxx' | grep $scn` 命令，通常可以发现一些重复打印的日志，分析这些日志可以找到一直重试的原因，如果 Clog 日志太多，上面的搜索中可以屏蔽掉 Clog 的日志，集中找其他模块的重复日志。

## 常见问题 2：回放慢

怀疑回放慢之前请先排查是否有卡住的问题。

1. 查 `__all_virtual_replay_stat` 表，观察 `end_lsn` 和 `unsubmitted_lsn` 的差距是否持续增大，此差值代表 `follower` 回放落后 `leader` 确认的日志量。

   ![image007.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice007.png)
 2. 如果 `pending_cnt` 持续不为 0 并保持在一个较高的数值（百级别以上），很可能单条回放慢的日志较多导致回放整体延迟，搜索单条回放慢的 OBServer 日志。

   通过 `grep 'cost too much time' observer.log | grep T1xxx | grep 'id:xxx'` 命令过滤关键词，获取回放信息。

   如果此类单条回放耗时 10ms 级及以上的日志较多，可以根据日志类型和线程号查看此日志回放时具体模块相关的日志。

   ![image008.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice008.png)
 3. 如果 `pending_cnt` 基本保持一个很低的值但 `end_lsn` 和 `unsubmitted_lsn` 的差距依然递增，很可能是因为 `barrier` 较多导致，可以搜索 `barrier` 回放日志。

   通过 `grep 'barrier log replay succ' observer.log | grep T1xxx | grep 'id:xxx'` 命令过滤关键词，获取 `barrier` 回放日志信息。

   统计一段时间内此日志的打印数可以大致估计出 `barrier` 日志的数量，如果 `barrier` 数量较多则会影响回放。

   ![image009.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice009.png)
 4. 如果 `barrier` 日志不是很多，继续排查是否为热点行。

   通过 `grep 'too much trans node scaned when row compact' observer.log | grep T1xxx_Replay` 命令过滤关键词，获取关键日志信息。

   如果发现此类日志，请联系 OceanBase 技术支持人员协助排查，继续分析是否为根因。
 5. 搜索如下日志排除回放限速导致回放进度推进慢。

   通过 `grep Txx_ReplayS observer.log |grep "Throttling"` 命令过滤关键词，如果发现此类日志可以确定是限速导致回放进度推进慢。
 6. 如果上述关键日志均不存在，可以根据表中的 `unsubmitted_lsn` 的增速算出拉日志的速度（隔 10s 中观察此列的增长值），目前回放的拉日志速度瓶颈为 400MB/s，如果速度基本达到此数量级说明已经达到了目前架构下 `follower` 回放的峰值，可以考虑降低 `leader` 的并发。

## 常见问题 3：漏回放日志

出于性能考虑，回放并不会每条日志回放时都打日志，但依然可以根据一些信息协助分析问题

1. 在日志流创建时间点附近搜索。

   通过 `grep 'enable replay status' observer.log.xxx | grep T1xxx | grep 'id:xxx'` 命令过滤关键词，获取相应信息。

   主要关注 `base_scn`，此时间戳为日志回放的起点，所有小于此 `ts` 的日志均不会回放。如果问题日志小于 `base_scn` 但数据不正确，可以继续排查是否转储位点推进不正常，或找到 `enable replay` 的线程分析入参的 `base_scn` 是否不合理。

   ![image010.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice010.png)
 2. 搜索最大已回放位点是否已经推过问题日志。

   通过 `grep 'get_min_unreplayed_log_info' observer.log | grep 'T1xxx' | grep 'id:xxx'` 命令过滤关键词，获取相应信息。

   ![image011.png](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240508replayservice011.png)

   `scn` 代表当前回放的上界，此scn之前的日志都已回放，如果问题日志的 `scn` 大于已回放位点，那么并没有漏，只是还没有回放。
 3. 如果问题日志的 `scn` 落在 `base_scn` 和最大回放位点之间，请联系 OceanBase 技术支持人员协助排查。

## 适用版本

OceanBase 数据库 V4.x 版本。

上一篇

[OceanBase 数据库 V1.4x 版本 meta 表有不符合预期的副本记录](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000284534)

下一篇

[如何优化增补副本、副本搬迁速率](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000150) ![有帮助](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) 咨询热线