errcode=-4184 磁盘空间不足导致租户长时间处于合并状态

【 使用环境 】生产环境
【 OB or 其他组件 】 4.2.0.0 CE版本
【 使用版本 】
【问题描述】某业务租户在执行每日合并操作后,某张表scn长时间没有推进,目前排查下来原因是数据盘空间不足,在合并期间写放大,使用的sstable超过 data_disk_usage_limit_percentage = 98 阈值无法继续推进合并。现场环境客户磁盘目前无法进行扩容,datafile_size 无法调大数据文件大小,sstable最大使用限制已经调到100%,是否有其他方式可以消除合并,或者跳过本次合并,防止阻塞后续的操作。
【附件及日志】
合并99%卡住问题排查.txt (7.1 KB)

@论坛小助手 是否有解决方法。

9 个赞

根据您描述的情况,OceanBase集群中某个租户因磁盘空间不足而长时间处于合并(compaction)状态,并且由于已经接近设定的磁盘使用率上限(98%),直接进行扩容或调整datafile大小变得不可行。针对这种状况,首先推荐使用obdiag工具来收集当前环境下的相关信息,这将有助于进一步诊断问题的根本原因以及探索可能的解决方案。

日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction

该命令会自动搜集与合并操作相关的日志和其他重要文件,帮助我们了解具体的合并过程为何停滞不前、是否存在潜在错误信息等。

另外,为能更准确地定位问题,请您提供以下详细信息:

  1. 这个租户的数据存储量大概有多大?是否有特别大的表或者索引?
  2. 磁盘空间不足的具体情况是什么样的?是整个集群的存储都满了还是只有特定的服务器/分区满了?
  3. 在出现此问题之前,是否有执行过大量写入操作或其他可能导致数据增长的操作?
  4. 您是否尝试了任何手动干预措施来解决这个问题,比如调整compaction策略参数?如果尝试过,请告知具体采取了哪些步骤及其结果。
  5. 除了提供的错误代码(-4184),在系统日志里是否还有其他异常记录或警告?

请运行上述给出的日志采集命令,并将生成的日志压缩包发送给我们。同时,基于上面列出的问题点尽可能多地分享相关细节,这对我们来说非常重要,以便尽快找到合适的处理方案。谢谢!

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

6 个赞

[2026-06-07 19:28:18.605450] INFO [RS] check_tablet_compaction_scn (ob_major_merge_progress_checker.cpp:481) [25077][T1002_MergeSche][T1002][YB420A042168-000605987BEBC902-0-0] [lt=127] replica not merged to target version or status not match(tenant_id=1002, current_version=1780682401315116260, global_broadcast_scn={val:1780768803189255053, v:0}, current_status=0, compaction_replica={tenant_id:1002, tablet_id:{id:1152921504606847159}, ls_id:{id:1002}, server:“192.168.33.104:2882”, snapshot_version:1780682401315116260, data_size:78448332115, required_size:80308338688, report_scn:1780682401315116260, status:0})

仅当前server:“192.168.33.104” 无法推进scn,另外两个节点无异常

4 个赞

论坛小助手回答的很详细,学习了。

1 个赞

合并没有跳过操作 104节点磁盘使用为什么这么高,是存在其他租户么。还是说本次合并导致?

2 个赞

清理日志、冷数据、回收站释放磁盘空间后再试试

2 个赞

学以致用。

2 个赞

又学到了一个知识

2 个赞

只有一个生产租户和sys租户,104 节点合并卡在一张LOB辅助表上 ,表名 _AUX_LOB_META_500271,看定义像是内部表,数据盘放在根目录下,磁盘空间用了97%,剩余空间无法继续扩容,磁盘需要预留一部分给系统日志使用。


合并报错是从昨天 6.7号开始,排查发现报错4184,查了官方资料说是磁盘空间不足导致的合并异常,目前已尝试给sstable扩容15G,还是无法推进合并。日志、冷数据当前已经没有可以清理的了。这种情况应该怎么处理。

如果 _AUX_LOB_META_500271 为内部表,是否可以设置渐近合并方式,对该表进行多次合并,减少单次增量合并对磁盘的消耗。

3 个赞

select data_size/1024/1024/1024, REQUIRED_SIZE/1024/1024/1024 from CDB_OB_TABLET_REPLICAS where tablet_id=1152921504606847159;
查询下这个看下

3 个赞

3 个赞

存在已知类似问题,这边先确认下

4 个赞

好的,辛苦了

2 个赞

学到了。

1 个赞

:+1: :+1:

1 个赞

厉害了

1 个赞

学习了

_AUX_LOB_META_500271是lob的辅助表
没有太好的解决方法,选择把这个副本删掉重建吧

1 个赞

干货满满,受益匪浅

1 个赞

老师,目前正在合并的104节点,删除副本需要先停止合并吗,或者能否提供下副本删除重建的具体流程吗,减少对生产的影响。

1 个赞