1. 背景
卡合并在OceanBase中是一个复杂的问题，其产生可能源于多种因素。目前，对于卡合并的明确界定尚不存在统一标准，一方面，我们界定超过36小时未完成合并为合并超时，此时RS会记录ERROR日志；另一方面，用户也可能依据自身经验来判断合并是否超时。当用户怀疑合并可能已超时，可利用巡检工具进行检查，以确认是否存在问题，并且得到一系列基础数据方便研发做一个初步的判断，省去一些反复沟通的时间。本文描述了 OceanBase 4.x 版本基于obdiag，如何进行卡合并的分析和诊断。
2. 卡合并诊断流程说明
2.1. 发现卡合并问题
巡检认为合并/转储存在潜在问题可以有三点：
- CDB_OB_MAJOR_COMPACTION里IS_ERROR=YES
- 其中当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的记录（需要收集回来）
-
- 可以先检查一下IS_ERROR和IS_SUSPENDED是否非NO，IS_ERROR通常发生在出现数据不一致的时候，INFO里会显示具体问题；IS_SUSPENDED表示暂停了合并，有时候会忘了执行过暂停合并操作，需要手动恢复合并（
ALTER SYSTEM RESUME MERGE;）
- 可以先检查一下IS_ERROR和IS_SUSPENDED是否非NO，IS_ERROR通常发生在出现数据不一致的时候，INFO里会显示具体问题；IS_SUSPENDED表示暂停了合并，有时候会忘了执行过暂停合并操作，需要手动恢复合并（
- 查询__all_virtual_compaction_diagnose_info，最好根据上面得到的结果，每个租户查一次，方便看（需要收集回来）。
- 如果有记录，根据DIAGNOSE_INFO字段的内容来具体分析。这里只介绍了一部分常见的信息，其他的目前还是考虑先把诊断表结果拿回来，我分析后再手动进行下一步：
- schedule medium failed
- 查找这台机器上，CREATE_TIME附近时间的observer.log，grep "decide_medium_snapshot"，捞到信息后，把线程号摘出来，更换过滤关键字grep "\[线程号]"，收集decide_medium_snapshot关键字前后20行的日志。通常里面会有报错上下文
- %error_no=%error_trace=%
- 这种情况通常有dag任务失败了，首先查__all_virtual_tablet_meta_table，看下这个分区的compaction_scn是否小于合并版本（global_broadcast_scn），如果小于再进行步骤2
- 在对应机器的对应时间附近，grep "error_trace"，收集这部分日志回来，整个trace的日志通常不会很多，尽可能捞到报错前后的日志。
- schedule medium failed
不影响正常流程的错误码！！！
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
-
-
- 查询对应租户和ls_id的__all_virtual_ls_info结果（收集）
- 过滤出weak_read_scn比合并版本（global_broadcast_scn）小的记录，到相应机器上在最新几个observer日志里grep "weak_read_scn+1的值"、"generate_weak_read_timestamp_"以及"log disk space is almost full"（收集）
- 如何进一步判断可以咨询日志或事务组同学
-
4. memtable can not create dag successfully
-
-
- 首先查__all_virtual_tablet_meta_table，看下这个分区的compaction_scn是否小于合并版本（global_broadcast_scn），如果小于再进行ii
- 查询这台机器这个租户的__all_virtual_dag_scheduler（收集回来）
-
5. medium wait for freeze或者major wait for freeze
-
-
- 查询这台机器这个租户的__all_virtual_dag_scheduler（收集回来）
-
6. major not schedule for long time
-
-
- 查询该分区的__all_virtual_tablet_compaction_info（收集回来）
- 到该机器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）的记录（收集回来）
-
- 如果当前版本的所有记录status都是FINISH，那么查询CDB_OB_LS_LOCATIONS，查到租户ls_id=1的leader机器，到该机器上查找最新的几个rootservice.log，grep "major_merge_progress_checker" | grep Txxxx，将日志收集回来
- 根据上一次合并记录中的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 技术交流
