【 使用环境 】测试环境
OB
【 使用版本 】OceanBase 4.2.1.4
【问题描述】在官方资料：OceanBase分布式数据库-海量数据 笔笔算数 存在如下描述
关于表 __all_virtual_server_compaction_event_history 官网没有找到相关资料，老师可以帮忙给下字段含义以及表的具体作用吗？提供一个查询结果如下（此时zone3是处于合并卡住状态，向RS汇报失败，这里的查询结果好像与资料写的不符）
查看合并状态可以使用__all_virtual_tablet_replica_info表，了解表副本的状态
推荐使用 GV$OB_TABLET_COMPACTION_HISTORY 视图来查询相应的信息。相关文档如下：
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219775
老师，能帮忙讲解下如何通过这个表查看租户合并汇报是否成功吗？event这里的TABLET_COMPACTION_FINISHED 是指该租户的 zone 下所有 TABLET 合并完成？
@辞霜 @与义
4.2.1是这几个event，目前在TABLET_COMPACTION_FINISHED是存储层tablet合并都合完了，看起来没有汇报的event。这种情况看这张表作用不大
你可以先试着用obdiag工具的合并根因诊断功能收集一下信息，命令是obdiag rca run --scene=major_hold
根因分析的使用文档：OceanBase分布式数据库-海量数据 笔笔算数
老师，我确认下：
select * from GV$OB_COMPACTION_PROGRESS where status = 'FINISH';
的结果是全部都是FINISH
或者
select * from __all_virtual_server_compaction_event_history where tenant_id = 1 and compaction_scn = $GLOBAL_BROADCAST_SCN and event like '%FINISHED%' order by zone;
结果为： TABLET_COMPACTION_FINISHED
这两者都代表存储层合并已完成，对么？
是的，这种情况下你通过GV$OB_SSTABLES看任意tablet的sstable分布，都会有一个最新合并版本的major sstable
老师，比如当前 SYS 租户的 GLOBAL_BROADCAST_SCN 等于 1718301602258513228
而 GV$OB_SSTABLES 表SYS租户的 END_LOG_SCN 全部等于 ‘1718301602258513228’ 则代表对应的MAJOR SSTABLE已经生成对吗？
是的话，END_LOG_SCN 等于1 是什么含义呢？
老师，再跟您请教下相关问题
一、下面这里的 REPORT: batch update tablets finished ，假如是合并涉及的 trace_id 可以理解为租户向 RS Leader 的__all_tablet_meta_table 汇报合并的信息对吗
https://sourcegraph.com/github.com/oceanbase/oceanbase/-/blob/src/observer/report/ob_tablet_table_updater.cpp?L806:37-806:55
比如：下面的语句是 1001租户向 __all_tablet_meta_table 进行 compaction_scn 的汇报
二、根据如下代码来看，只有 SYS租户 或者 META 租户需要对 __all_tablet_meta_table 进行信息汇报，对吗？
https://sourcegraph.com/github.com/oceanbase/oceanbase/-/blob/deps/oblib/src/lib/ob_define.h?L1619:20-1619:38
三、合并过程涉及如下event，前5个步骤，我看可以在 __all_virtual_server_compaction_event_history 中看到，后4个步骤有相关视图或者表可以查看吗？还是只能通过日志判断呢
1 个赞
- 是的
- END_LOG_SCN 等于1 的是第一个major，也就是初始时候的那个major
- 可以这样理解.汇报这件事存储层是把任务丢给ObTabletTableUpdater，然后ObTabletTableUpdater自己去取任务队列里的任务进行执行。通过看日志里的compaction_scn可以将汇报任务和具体版本的合并对应起来。不过存储层的合并和ObTabletTableUpdater更新meta表是两个任务线程，trace_id应该不是相同的
- 这个是因为这张表是在meta租户下的，所以代码里需要切到租户对应的meta租户去执行更新inner sql。你可以试试在用户租户/meta租户下分别查询__all_tablet_meta_table看看。
- 你看的是最新的代码，后面更新了更多的event记录，这些event都可以在__all_virtual_server_compaction_event_history里看到的，是相对应的
1 个赞
另外为你看源码解决问题的方式点赞
1 个赞
感谢老师解答，再请教您如下问题
1、本环境昨晚 02:00 完成过合并，但我在这个表不加条件进行关键字模糊检索后4个字段，没有找到相关信息，是我查询方式有误么？
2、老师，可以帮忙简单介绍下这几个字段的含义吗
“RECEIVE_BROADCAST_SCN”,
“GET_FREEZE_INFO”,
“WEAK_READ_TS_READY”,
“SCHEDULER_LOOP”,
“TABLET_COMPACTION_FINISHED”,
“COMPACTION_FINISH_CHECK”,
“COMPACTION_REPORT”,
“RS_REPAPRE_UNFINISH_TABLE_IDS”,
“RS_FINISH_CUR_LOOP”
3、__all_tablet_meta_table 这张表只存在于 SYS/META租户，假如存在业务租户1002，对应的META租户是1001
1002 租户合并完成之后是由1002租户切至1001租户进行汇报，加上1001租户合并完成自己汇报，两个租户都会单独进行汇报，对吗？
1.既然你看了代码，其实这个问题可以从代码里找答案，event是存在租户级的ObServerCompactionEventHistory结构里的，它是以一个固定长度的ring array实现的，上限是500，也就是最多只能存500条记录，之前的event大概率是被冲掉了
2. 你顺着这些关键字找代码其实就能看到合并调度的整个流程。
“RECEIVE_BROADCAST_SCN”, 存储层调度器ObTenantTabletScheduler开始合并
“GET_FREEZE_INFO”, 这个现在没用
“WEAK_READ_TS_READY”, 所有需要合并的日志流的弱读时间戳准备好，即弱读时间戳已经大于合并版本
“SCHEDULER_LOOP”, 简单理解就是调度器正在轮询分区，发起每个分区的合并任务
“TABLET_COMPACTION_FINISHED”, 所有分区合并完成，这里的标准是最新major的位点大于等于合并位点
“COMPACTION_FINISH_CHECK”, 检查副本间的scn和checksum是否都一致
“COMPACTION_REPORT”, 这个现在没用
“RS_REPAPRE_UNFINISH_TABLE_IDS”, RS准备待合并表的相关信息，这个其实是处在合并最开始的时候
“RS_FINISH_CUR_LOOP” RS完成一轮合并，这里是整个合并（存储和RS端）的相关处理都完成了
3. 对
1 个赞
好的，我再研究下，感谢老师极高质量的解答