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

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

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

如何确认回放卡

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

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

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 日志：

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

   输出内容如下：

   

   此日志会重复打印，根据其中任意一条的 err_ts_ 找到对应的报错时间（select usec_to_time(err_ts_) from dual），err_ret_ 是回放报错的错误码。

2. 搜索报错时间附近的 OBServer 日志找到报错的起始点，并找到对应的线程。

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

   输出内容如下：

   

3. 根据线程找到回放报错时的详细链路堆栈信息，分析链路中错误码吐出的原因即可定位问题。

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

   输出内容如下：

   

其他场景

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

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

   输出内容如下：

   

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

   • 如果几次的结果均不同，则可以转到 常见问题 2：回放慢 这一节，按照回放慢的逻辑排查。

   • 如果几次结果均相同，则表示回放位点卡住。转到步骤 2 。

2. 需要继续日志确认卡的原因。

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

   输出内容如下：

   

   • 其中 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 来过滤对应日志流的回放日志：

   

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

常见问题 2：回放慢

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

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

   

2. 如果 pending_cnt 持续不为 0 并保持在一个较高的数值（百级别以上），很可能单条回放慢的日志较多导致回放整体延迟，搜索单条回放慢的 OBServer 日志。

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

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

   

3. 如果 pending_cnt 基本保持一个很低的值但 end_lsn 和 unsubmitted_lsn 的差距依然递增，很可能是因为 barrier 较多导致，可以搜索 barrier 回放日志。

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

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

   

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 是否不合理。

   

2. 搜索最大已回放位点是否已经推过问题日志。

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

   

   scn 代表当前回放的上界，此scn之前的日志都已回放，如果问题日志的 scn 大于已回放位点，那么并没有漏，只是还没有回放。

3. 如果问题日志的 scn 落在 base_scn 和最大回放位点之间，请联系 OceanBase 技术支持人员协助排查。

适用版本

OceanBase 数据库 V4.x 版本。