【OceanBase诊断调优】—— obdiag 一条命令搞定卡合并问题根因分析

news2025/1/21 4:55:01

1. 背景

卡合并是一个OceanBase中较为复杂的问题，可能由各种问题引入导致。当前是否卡合并无明确定义，一方面我们认为超过36小时没合完是合并超时（RS会报ERROR日志），另一方面用户可能自己判断合并超时（根据用户自己的经验）。因此当用户认为合并可能已经超时的时候，可以通过巡检工具来检查是否真的存在问题，并且得到一系列基础数据方便研发做一个初步的判断，省去一些反复沟通的时间。本文OceanBase 4.x 版本描述基于obdiag的卡合并根因分析是如何实现的。

2. 卡合并诊断流程说明

2.1. 发现卡合并问题

巡检认为合并/转储存在潜在问题可以有三点：

CDB_OB_MAJOR_COMPACTION里IS_ERROR=YES
1. 其中当CDB_OB_MAJOR_COMPACTION里IS_SUSPENT=YES，可以提示用户，用户可能是有意设置也有可能是无意设置
__all_virtual_compaction_diagnose_info里存在status=FAILED的记录
GV$OB_COMPACTION_PROGRESS表中，根据上一次合并记录中的data_size/(estimated_finish_time-start_time)与当前合并版本记录中(data_size-unfinished_data_size)/(当前时间-start_time)相比，如果差距过大（当前合并比上一次合并慢很多，以5倍为指标），那可能可以认为合并存在异常

2.2. 卡合并诊断

2.2.1. 确定合并记录

查询CDB_OB_MAJOR_COMPACTION，找到status=COMPACTING的记录（需要收集回来）

1. 可以先检查一下IS_ERROR和IS_SUSPENDED是否非NO，IS_ERROR通常发生在出现数据不一致的时候，INFO里会显示具体问题；IS_SUSPENDED表示暂停了合并，有时候会忘了执行过暂停合并操作，需要手动恢复合并（ALTER SYSTEM RESUME MERGE;）

1726058071

查询__all_virtual_compaction_diagnose_info，最好根据上面得到的结果，每个租户查一次，方便看（需要收集回来）。
如果有记录，根据DIAGNOSE_INFO字段的内容来具体分析。这里只介绍了一部分常见的信息，其他的目前还是考虑先把诊断表结果拿回来，我分析后再手动进行下一步：
1. schedule medium failed
  1. 查找这台机器上，CREATE_TIME附近时间的observer.log，grep "decide_medium_snapshot"，捞到信息后，把线程号摘出来，更换过滤关键字grep "\[线程号]"，收集decide_medium_snapshot关键字前后20行的日志。通常里面会有报错上下文
2. %error_no=%error_trace=%
  1. 这种情况通常有dag任务失败了，首先查__all_virtual_tablet_meta_table，看下这个分区的compaction_scn是否小于合并版本（global_broadcast_scn），如果小于再进行步骤2
  2. 在对应机器的对应时间附近，grep "error_trace"，收集这部分日志回来，整个trace的日志通常不会很多，尽可能捞到报错前后的日志。

不影响正常流程的错误码！！！
constexpr int OB_NO_NEED_MERGE = -4677; // 调度的时候发现可以做Compaction，实际执行时发现不满足Compaction要求
constexpr int OB_CANCELED = -4072; // dag任务被cancel掉，上层逻辑停止了compaction任务
如果是scheduler报错4072，怀疑是执行了suspend merge，需要resume merge

--4.0版本--
constexpr int OB_TABLE_IS_DELETED = -4279; // 表被删除
constexpr int OB_TENANT_HAS_BEEN_DROPPED = -5685; //租户被删
constexpr int OB_LS_NOT_EXIST = -4719; // 日志流不存在
constexpr int OB_TABLET_NOT_EXIST = -4725; //表被删

比较危险的错误
constexpr int OB_CHECKSUM_ERROR = -4103; // 数据checksum报错
constexpr int OB_ROWKEY_ORDER_ERROR = -4105; // rowkey乱序
constexpr int OB_PHYSIC_CHECKSUM_ERROR = -4108; // 物理checksum问题，多发现于物理盘有问题
constexpr int OB_CS_OUTOF_DISK_SPACE = -4184; // datafile中没有空闲宏块时报错，表示集群写的数据达到上限。需要扩展存储空间

3. weak read ts is not ready

1. 1. 查询对应租户和ls_id的__all_virtual_ls_info结果（收集）
  2. 过滤出weak_read_scn比合并版本（global_broadcast_scn）小的记录，到相应机器上在最新几个observer日志里grep "weak_read_scn+1的值"、"generate_weak_read_timestamp_"以及"log disk space is almost full"（收集）
  3. 如何进一步判断可以咨询日志或事务组同学

4. memtable can not create dag successfully

1. 1. 首先查__all_virtual_tablet_meta_table，看下这个分区的compaction_scn是否小于合并版本（global_broadcast_scn），如果小于再进行ii
  2. 查询这台机器这个租户的__all_virtual_dag_scheduler（收集回来）

5. medium wait for freeze或者major wait for freeze

1. 1. 查询这台机器这个租户的__all_virtual_dag_scheduler（收集回来）

6. major not schedule for long time

1. 1. 查询该分区的__all_virtual_tablet_compaction_info（收集回来）
  2. 到该机器observer.log 查找grep "MediumLoo" | grep T租户id，然后摘出线程号，更换关键词grep "\[线程号]"，在最新日志里收集1000行日志

3. 查询GV$OB_COMPACTION_PROGRESS，指定租户和compaction_scn，分别查compaction_scn=当前合并版本global_broadcast_scn以及compaction_scn=上一个合并版本（last_scn）的记录（收集回来）

1. 如果当前版本的所有记录status都是FINISH，那么查询CDB_OB_LS_LOCATIONS，查到租户ls_id=1的leader机器，到该机器上查找最新的几个rootservice.log，grep "major_merge_progress_checker" | grep Txxxx，将日志收集回来
2. 根据上一次合并记录中的data_size/(estimated_finish_time-start_time)与当前合并版本记录中unfinished_data_size/当前时间-start_time相比，如果差距过大（当前合并比上一次合并慢很多），那可能可以认为合并存在异常

4. 查询GV$OB_COMPACTION_SUGGESTIONS，把结果收集回来

5. 查询oceanbase.__all_virtual_dag_warning_history，收集status="RETRYED"，type like "%MERGE%"的结果。并收集gmt_create附近时间点的observer日志，过滤task_id。