当前位置：首页 > news >正文

如何用 obdiag 排查 OceanBase数据库的卡合并问题——《OceanBase诊断系列》14

news 2026/2/11 1:42:51

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。

4. 如何借助obdiag来快速处理卡合并问题

目前阶段卡合并场景主要用于初步的分析定位及有效信息收集，需要在完成后将收集的有效信息进行打包并上传社区问答区或 OceanBase 运维进行进一步分析。

obdiag rca run --scene=major_hold

案例参考：OB社区版4.2.1 1T数据量10G以下数据增量每日合并时间20小时左右如何优化

4. 后续场景升级

目前实现仅作为排查的信息收集对于底层的分析未实现，后续将逐步进行深入的根因分析

有兴趣的DBA和开发者可以加入obdiag SIG进行共建开发。

5. 技术支持

排查思路及流程感谢镜水（胡皓胜）提供。

附录

•obdiag 下载地址： https://www.oceanbase.com/softwarecenter

•obdiag 官方文档： https://www.oceanbase.com/docs/obdiag-cn

•obdiag github地址： GitHub - oceanbase/obdiag: obdiag (OceanBase Diagnostic Tool) is designed to help OceanBase users quickly gather necessary information and analyze the root cause of the problem.

•obdiag SIG 营地： [obdiag SIG] 诊断工具组 · OceanBase 技术交流