compaction_diagnose 视图使用指南

本文主要介绍 compaction 合并中诊断视图的使用。

适用版本

OceanBase 数据库 V3.2 及以后的版本。

合并诊断视图

在 Compaction 出现异常的情况下，OBServer 会收集相关信息用于原因诊断。

用法：

```
select * from __all_virtual_compaction_diagnose_info;
```

```
select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
```

通过 STATUS 来过滤信息的严重程度，从低到高：

• SPECIAL：用来输出一些相同问题的 tablet 数量。

• RS_UNCOMPACTED：不一定存在异常。说明还存在 tablet 版本尚未推高至当前合并版本号，可以先通过 GV$OB_COMPACTION_PROGRESS 判断是否处于正常合并进行的状态。如果还有 RUNNING 的合并，则大概率是合并任务的问题。

• NOT_SCHEDULE：表示 compaction 长时间未被调度。比较常见的是出现在 follower 上，由于 medium info 的同步落后导致的合并未调度；以及由于 DAG 数量超限导致的 MINI 未调度。

• FAILED： 表示出现一些明显的异常。

主要通过 DIAGNOSE_INFO 字段的信息来定位问题，该字段可能包含以下信息。

• major or medium may be suspended

  • 原因： could_major_merge = false，暂停了 major; could_schedule_medium = false，暂停了 medium。
  • 解决方式：首先看下 CDB_OB_MAJOR_COMPACTION，确认是否有 IS_SUSPENDED 状态的记录，如果有，那么说明执行过暂停合并的操作ALTER SYSTEM SUSPEND MERGE;，需要手动恢复合并 ALTER SYSTEM RESUME MERGE;。如果没有，联系技术支持人员协助排查（存储模块）。

• schedule medium failed

  • 原因：具体原因看信息中的 error_code。
  • 解决方式：查看 observer 日志，过滤 decide_medium_snapshot 或信息中的 error_code 关键字，找到报错的上下文。

• error_no=xxx ... error_trace=xxx ...

  • 原因：存在 DAG 任务失败。
  • 解决方式：查看信息是否可以定位根因，如果不能则在日志中查找 error_trace，找到报错的上下文。

• refresh ls locality cache failed

  • 原因：ls locality cache 刷新失败，信息中会包含错误码。
  • 问题：可能导致合并的一些校验失败。
  • 排查手段：在 observer 日志里搜 refresh ls locality 关键字找到 trace，再搜索 trace_id 查看上下文。如果 WARN 日志不是近段时间的，大概率已经恢复正常。（由于该信息在合并结束后清理，因此会滞留一段时间）

• weak read ts is not ready

  • 原因：备机读时间戳未推过 major 合并位点。
  • 可能导致的结果：合并超时。
  • 解决方式：联系技术支持人员协助排查（事务模块）。

• memtable can not minor merge

  • 原因：MEMTable 未达到转储条件。
  • 可能导致的结果：Mini Compaction 慢、clog 回收慢、内存爆。
  • 解决方式：联系技术支持人员协助排查（事务模块）。

• memtable rec_scn/rec_log_ts not stable

  • 原因：日志流冻结过程中连续最大回调(放)点长时间没有推过对应 tablet 的 MEMTable 的 rec_log_ts。
  • 更深层次的原因是回调(放)慢。
  • 解决方式：联系技术支持人员协助排查（事务模块）。

• memtable not ready for flush

  • 原因：日志流冻结过程中有 MEMTable 长时间没有达到转储条件。
  • 可能导致的结果：转储超时/内存爆。
  • 解决方式：联系技术支持人员协助排查（事务模块）。

• memtable can not create dag successfully

  • 原因：MEMTable 达到转储条件后，长时间没有成功发起转储任务。
  • 解决方式：联系技术支持人员协助排查（事务模块）。

• traverse_trans_to_submit_redo_log failed

  • 原因：提交 redo log 失败解决方式：联系技术支持人员协助排查（事务模块）。

• sstable count is not safe

  • 原因：SSTable 数量过多，导致无法做 Mini compaction。
  • 可能导致的结果：无法做 Mini Compaction、clog 回收慢、内存爆。

  diagnose_info 还会展示导致 SSTable 数量过多的原因：

    * SNAPSHOT_FOR_MAJOR：Major compaction
    * SNAPSHOT_FOR_DDL：表的 DDL 例如建索引
    * SNAPSHOT_FOR_MULTI_VERSION：多版本数据过多，undo_retention 过大
    * SNAPSHOT_FOR_RESTORE_POINT：restore_point
    * SNAPSHOT_FOR_BACKUP_POINT：备份相关
  

• dag may hang

  • dag 一段时间未更新，可能卡住，如果超过 10min 一直保持这个状态，联系技术支持。

• freeze_info is invalid

  • 原因：获取 freeze_info 失败。
  • 可能导致的结果：合并超时。
  • 解决方式：联系技术支持人员协助排查（存储模块）。

• can't schedule minor merge

  • 原因：mini sstable 数量过多但依然没有成功调度 minor merge。
  • 根因有多种，需要进一步定位。
  • 解决方式：联系技术支持人员协助排查（存储模块）。

• need major merge but can't merge now

  • 原因：tablet 的 snapshot 小于合并版本，需要等新的转储。

• merge has been paused

  • 原因：合并被暂停了。
  • 解决方式：ALTER SYSTEM RESUME MERGE; 恢复合并。

• medium wait for freeze，xxx（major wait for freeze，xxx）

  • 原因：该机器的 medium/major 超过 interval 时间还在等待冻结/转储。其中 compaction_scn 为此次合并的 scn，tablet_snapshot 为 tablet 的 snapshot_version。通常这种情况下compaction_scn>tablet_snapshot，即该分区还没有做一次转储来使得 tablet_snapshot 推过 compaction_scn（这是合并调度的前置条件）。一般有三种情况：
    • 转储任务存在，在等待调度执行。
    • 转储一直发起失败。
    • 转储一直执行失败。
  • 解决方法：对于情况 1，查询 __all_virtual_dag 查看是否有对应的转储 DAG 存在，对于情况 2/3，通常诊断表里会有信息。等待转储没有很好的方法论，难以排查的话请转交存储同学排查。

• major not schedule for long time，xxx

  • 原因：该机器的 major 超过 interval 时间还没有调度。其中 max_receive_medium_snapshot 表示该分区在该机器收到的最大的 compaction_scn，compaction_scn 表示此次合并的 scn。通常这种情况下max_receive_medium_snapshot<compaction_scn，即该分区还没有被调度，一般有两种情况：
    • max_receive_medium_snapshot 版本的合并仍然有副本未完成。
    • max_receive_medium_snapshot 合并已完成，但新的调度暂未发起。
  • 解决方法：对应情况 1，查询 __all_virtual_dag 查看是否有对应的合并 DAG 存在，如果是合并任务执行失败通常诊断表里会有相关信息；对于情况 2，在日志里查找 MediumLoo 关键字，找到合并调度的线程，然后查找调度线程的线程号（如"[xxxxx]")，看是否有 WDIAG 的异常。合并未调度没有很好的方法论，难以排查的话请转交存储同学排查。

• maybe bad case: locality change and leader change

  • 原因：遇上 locality 变更且切主的 bad case。比如增加 locality，而日志流 Leader 被切到新增 Zone 上。
  • 解决方式：中断 locality 变更。
  • 如何确认该场景：
    • 首先查询 select * from __all_tenant where tenant_id = xxx;，查看 previous_locality 字段是否为空，如果不为空，那么说明正在进行 previous_locality->locality 变更的过程。
    • 然后查询 select * from CDB_OB_LS_LOCATIONS where tenant_id = xx and ls_id = xx，查看 leader 是否是 locality 变更中新增的 zone。如果是，则遇到 locality 变更，且日志流 leader 被切到新增 zone 的 bad case。

• compaction has finished in storage

  • 原因：存储层合并结束但 RS 后续处理未完成后续操作。
  • GV$OB_COMPACTION_PROGRESS 确定合并是否已经是 FINISH 状态。

• there is too many tablets. tablet count xxx

  • 原因：非异常。诊断时需要遍历的分区过多，跳过了该 ls 的诊断。

• 其他

  • 如果 status 字段为 RS_UNCOMPACTED，说明还存在 tablet 版本尚未推高至当前合并版本号，需要联系技术支持进一步排查是否卡合并。