适用版本
OceanBase 数据库 V4.2.1 BP3(oceanbase-4.2.1.3-103000052023122809) 版本。
问题描述
备租户合并卡住，并且导致合并卡住的对应的 tablet 在 __all_virtual_tablet_compaction_info 表中 extra_info 的 last_medium_scn 与第一个 medium_info 的 last_medium_snapshot 不匹配。
问题诊断
触发条件
备份和 medium compaction 并发，并且备份转储和备份基线在不同的 server 上，并且备份转储时候备份的 tablet 的快照版本比备份基线时候备份的 tablet 的快照版本要大。
事前巡检
该问题触发的条件没有特别好的巡检手段，原因是对应的 medium compaction 是 tablet 级别的，是系统自适应的一个 compaction，有可能在数据备份的期间任何时刻发生，由于备份丢失了连续性校验的代码逻辑，会导致这种情况不被发现，导致数据备份成功，但是之后恢复成备租户然后合并卡住。
事后诊断
备租户合并卡住，先找到导致合并卡住的那个 tablet，然后查询 __all_virtual_tablet_compaction_info 表中 extra_info 的 last_medium_scn 和第一个 medium_info 的 last_medium_snapshot 是否匹配。 正常的情况下，这两者是匹配的。
{extra_info:{info:4353, compat:1, last_compaction_type:1, wait_check_flag:1, last_medium_scn:1705255204893719000}, size:1, info_list:{[0]:compaction_type:"MEDIUM_COMPACTION", medium_snapshot_:1705286089631769000, last_medium_snapshot:1705255204893719000, parallel_merge_info:{list_size:0, compat:1, }}}
问题原因
在之前备份性能优化的改造中在备份期间丢失了对备份数据的连续性检查，备份转储和备份基线是两个阶段，由于缺少了备份的连续性校验，在备份转储阶段对应出现问题的 tablet 的合并快照版本比备份基线阶段对应出现问题的 tablet 的合并快照版本大，当用户恢复使用这个有问题的备份集进行恢复，然后转为备库，然后进行备库合并的时候，会导致合并的时候卡住。
解决方法
升级 OceanBase 数据库版本到 V4.2.1 BP4(oceanbase-4.2.1.4-104000062024022914) 及之后的版本，再进行数据备份。
规避方法
如果问题已经出现，则没有规避手段。
如果问题暂时还没有出现，可以先关闭租户级别的自适应 compaction 配置项。
obclient> alter system set _enable_adaptive_compaction = False tenant = xxx;然后保证数据备份和合并不正交，即用户先保证合并完成后再进行数据备份。
