租户合并卡住，报错4016

【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.5.4-104000042025090916
【问题描述】租户合并卡住

日志信息来看像是压缩算法发生变化，合并过程中检测到了schema变化但未能通过渐进式合并方式处理，导致4016，进而合并过程卡住。咨询下有什么办法可以临时处理？

【复现路径】问题出现前后相关操作
【附件及日志】

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

针对您描述的问题，在租户合并过程中遇到错误 4016 导致卡住，并且日志中提到压缩算法的变化和 schema 变化未能通过渐进式合并处理，建议先使用 obdiag 进行相关日志的收集，以便进一步分析问题的根本原因。根据您的情况，推荐的日志采集场景是“合并问题”，因为这直接关联到了您遇到的租户合并时出现的问题。

日志采集场景: 合并问题
日志采集命令:

obdiag gather scene run --scene=observer.compaction

此命令将帮助收集与合并相关的系统信息及日志，有助于我们更准确地定位问题所在。请运行上述命令后，将生成的日志文件打包发给我们进行深入分析。

为了更好地理解和解决您遇到的问题，请提供以下更多信息：

1. 您是否近期对相关租户执行了任何变更操作，例如修改了表结构或者调整了存储参数？
2. 错误发生前后的具体操作记录或日志详情是什么样的？特别是与压缩算法配置更改、schema 修改相关的部分。
3. 能否提供受影响租户的具体名称及其当前状态（如是否可正常访问）？
4. 系统监控数据（如 CPU 使用率、内存占用等）显示是否有异常波动？

这些信息将极大帮助我们缩小问题范围，更快找到解决方案。感谢您的配合！

附上敏捷诊断工具 obdiag 使用帮助链接

看起来像是命中了内核bug，帮忙评估一下

租户 1096 合并卡住，看着是部分 tablet（如 table 1001 / tablet 216135 等）在 build_ctx_after_init 阶段反复返回 -4016，导致 Major/Medium 合并均失败；RS 调度仍在运行，但无法完成最后约 35% 的 tablet，因此进度停在 65.08%。

– 查看失败 tablet 及诊断信息
SELECT tenant_id, type, tablet_id, status, create_time, diagnose_info
FROM GV$OB_COMPACTION_DIAGNOSE_INFO
WHERE tenant_id = 1096 AND status = ‘FAILED’
ORDER BY create_time DESC
LIMIT 50;

– 查看未完成合并进度
SELECT svr_ip, svr_port, zone, ls_id, tablet_id,
total_tablet_count, unfinished_tablet_count,
data_size, unfinished_data_size, status
FROM GV$OB_COMPACTION_PROGRESS
WHERE tenant_id = 1096 AND type = ‘MAJOR_MERGE’
AND status != ‘FINISH’;

日志信息 查看
grep -E “progressive round on schema is less than meta|found schema changed when compare|stored col cnt in curr schema is less” observer.log | tail -50

grep “tablet_id=216135” observer.log | grep -E “STORAGE_COMPACTION|failed to build ctx|cal_major_merge_param” | tail -30

对失败 tablet 对应表（如 table_id=1001 ）检查：
– 表 progressive merge 配置
SELECT table_id, table_name, progressive_merge_num, progressive_merge_round
FROM oceanbase.__all_table
WHERE tenant_id = 1096 AND table_id = 1001;

– tablet 合并信息
SELECT tablet_id, compaction_scn, status,
progressive_merge_round, progressive_merge_num
FROM GV$OB_TABLET_COMPACTION_INFO
WHERE tenant_id = 1096
AND tablet_id IN (216135, /* 其他失败 tablet_id */)
ORDER BY tablet_id;

–确认近期针对这些table_id是否有DDL操作