【 使用环境 】生产环境
【 OB or 其他组件 】observer
【 使用版本 】 4.2.1.1
【问题描述】租户卡合并
【复现路径】问题出现前后相关操作
【附件及日志】使用obdiag进行卡合并根因分析
obdiag_major_hold_20240709105801.tar.gz (13.6 KB)
ps:上传图标太灰了，不太好找
你好，帮忙收集一下如下信息
查询目前合并状态
select * from CDB_OB_MAJOR_COMPACTION;
查看当前存在多少tablet合并卡住
select count(*) from GV$OB_COMPACTION_PROGRESS where tenant_id = 1032 and compaction_scn = 1720461603092118628 and STATUS != “FINISH”;
查看合并进度中的tablet或者长时间未完成的tablet
select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
查询tablet基本合并进度
select * from GV$OB_TABLET_COMPACTION_PROGRESS;
select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
帮忙执行下
MySQL [oceanbase]> select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
±--------------±---------±----------±-------------±--------------------±--------------------±-------±---------------------------±-----------------------------------------------------------------------------+
| SVR_IP | SVR_PORT | TENANT_ID | TYPE | LS_ID | TABLET_ID | STATUS | CREATE_TIME | DIAGNOSE_INFO |
±--------------±---------±----------±-------------±--------------------±--------------------±-------±---------------------------±-----------------------------------------------------------------------------+
| 10.172.146.97 | 2882 | 1032 | MEDIUM_MERGE | 9223372036854775807 | 9223372036854775807 | FAILED | 2024-07-08 14:48:08.013998 | schedule_suspect_info=“info=“refresh ls locality cache failed”;errno=-4016;” |
±--------------±---------±----------±-------------±--------------------±--------------------±-------±---------------------------±-----------------------------------------------------------------------------+
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209906?back=kb
- refresh ls locality cache failed
- 原因：ls locality cache 刷新失败，信息中会包含错误码。
- 问题：可能导致合并的一些校验失败。
- 排查手段：在 observer 日志里搜
refresh ls locality关键字找到 trace，再搜索 trace_id 查看上下文。如果 WARN 日志不是近段时间的，大概率已经恢复正常。（由于该信息在合并结束后清理，因此会滞留一段时间）
如果1032租户9号凌晨2点的合并还没有结束，可以提供一下 10.172.146.97 节点最新的observer.log 看看。
找一个具体的 traceid 将过滤后的日志附件提供一下看看。
根据提供的日志看当时 1032 租户的队列有积压了
[2024-07-09 12:27:17.617588] WDIAG [COMMON] inner_add_dag (ob_dag_scheduler.cpp:3436) [20163][T1032_MediumLoo][T1032][YB420AAC9261-000609A0E1A574E2-0-0] [lt=16][errcode=-4019] ObTenantDagScheduler is full(ret=-4019, dag_limit=15000, dag={ObIDag:{this:0x7f6dcdb35b20, type:2, name:“MAJOR_MERGE”, id:Y0-0000000000000000-0-0, dag_ret:0, dag_status:0, start_time:0, running_task_cnt:0, indegree:0, consumer_group_id:0, hash:7485748907269767596}, param:{merge_type:“MEDIUM_MERGE”, merge_version:1720461603092118628, ls_id:{id:1002}, tablet_id:{id:1152921504607413889}, report_:null, for_diagnose:false, is_tenant_major_merge:true, need_swap_tablet_flag:false}, compat_mode:0, ctx:null})
需要使用obdiag收集有积压的时候的 obstack 进一步分析。
obdiag gather stack
使用的详细说明：OceanBase分布式数据库-海量数据 笔笔算数
obdiag gather stack
你好，该问题还存在么，如果还在麻烦使用obdiag收集一下信息
该问题已经在叮群答复，收集当时有积压的时候的obstack导致