首批通过分布式安全可靠测评,为关键业务系统打造
租户 table history 过多导致重启时 schema 刷新报错 -4013 的原因及解决方法
更新时间:2026-06-10 01:56
问题现象
集群某个租户 table history 过多,机器重启的时候 schema 刷新会持续报 -4013,导致某台机器对应租户的 schema 无法刷新出来。
关键诊断信息
触发条件
集群某个租户 table history 过多,机器重启。
事前巡检
select tenant_id, count(*) from oceanbase.__all_virtual_table_history group by 1 having count(*) > 4000000;
select tenant_id, count(*) from oceanbase.__all_virtual_table group by 1 having count(*) > 2500000;
当上述二语句查询有值,集群为未修复版本时,重启有风险。
事后诊断
关键日志信息。
[2023-09-06 22:23:43.636622] WARN common_alloc (ob_tenant_ctx_allocator.cpp:427) [9959][SerScheQueue1][T0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=5][errcode=-4013] No memory or reach tenant memory limit([OOPS]="alloc failed reason", msg=single alloc size large than 4G is not allowed(alloc_size: 10223120000))
[2023-09-06 22:23:43.636631] WDIAG common_alloc (ob_tenant_ctx_allocator.cpp:432) [9959][SerScheQueue1][T0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=7][errcode=-4013] oops, alloc failed, tenant_id=500, ctx_id=0, ctx_name=DEFAULT_CTX_ID, ctx_hold=6026690560, ctx_limit=9223372036854775807, tenant_hold=6340599808, tenant_limit=9223372036854775807
日志中有 500 租户单次内存分配超 4G 的 ERROR。
问题原因
OceanBase 数据库 V4.1.0 BP2 版本修复了 table history 过多时重启 schema 刷新超时的问题,该修复引入了一个内存预分配的逻辑,但是该预分配逻辑参考的是 table history 的数目,而不是存量 table 的数目,导致会分配比实际所需更多的内存。
问题的风险及影响
触发该问题会导致 OBServer 无法起来。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响版本
OceanBase 数据库企业版 V4.1.0 BP2(oceanbase-4.1.0.1-102000042023061309)及之后版本。
解决方法
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.1.0 BP4(oceanbase-4.1.0.2-104000032023092119)。
没有很好的解决方案,需要强制删除租户或者手工清理 table history 恢复。
警告
需要强制删除租户或者手工清理 table history 恢复的操作存在风险,请勿自行操作。如果需要操作,请咨询 OceanBase 技术支持。
规避方式
-- 若二语句查询有值,集群为未修复版本时,重启有风险
select tenant_id, count(*) from oceanbase.__all_virtual_table_history group by 1 having count(*) > 4000000;
select tenant_id, count(*) from oceanbase.__all_virtual_table group by 1 having count(*) > 2500000;
集群巡检是否 schema 量级达到危险水位线,及时升级到修复该问题的版本。