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

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

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

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

日志常见问题排查步骤

无主

根据 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 问题 进行排查。

如果 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 盘满如何排查，找到并解决导致盘满的问题源。

适用版本

OceanBase 数据库 V4.x 版本。