问题现象
备份期间磁盘使用率上升，在磁盘水位线本身已经较高的情况下，可能达到 data_disk_usage_limit_percentage（默认 95%）而导致备份因 4184（OB_SERVER_OUTOF_DISK_SPACE）失败。特别地，在备份和合并并发的情况下，磁盘膨胀率可能更高。
关键诊断信息
预估备份的磁盘占用量
对于每个备份线程，大致流程如下：
取一批 tablet_id（最多 2000 个）。
保留这些 tablet 的某个版本的全量数据。
备份这些数据。
释放这些版本，允许其被回收。
为了避免过多占用磁盘，备份还存在如下限制：
如果这一批 tablet 的数据已经超过了 4GB，则最多只保留 4GB，剩余 tablet 留待下一批处理。
如果单个 tablet 的数据超过了 4GB，则本次只保留这一个 tablet。
因此，理论上最坏情况下备份会保留前 N 个最大的 tablet，其中 N 是备份并发度 ha_low_thread_score。
以下是进一步确认的方法：
查看前 N 个最大 tablet 的数据量（这里以 N=10 为例）。
select tablet_id, required_size/1024/1024/1024 from __all_virtual_tablet_pointer_status where tenant_id = xxx and svr_ip="xxx" order by required_size desc limit 10; +---------------------+------------------------------+ | tablet_Id | required_size/1024/1024/1024 | +---------------------+------------------------------+ | 1152921504606847536 | 293.515628814697 | | 1152921504606847537 | 204.925785064697 | | 1152921504606847545 | 179.583988189697 | | 1152921504606847248 | 125.172180175781 | | 1152921504606847302 | 112.394847869873 | | 1152921504606847543 | 111.015628814697 | | 1152921504606847694 | 66.631416320801 | | 1152921504606847538 | 63.150394439697 | | 1152921504606847688 | 62.768199920654 | | 1152921504606847539 | 62.333988189697 | +---------------------+------------------------------+ 10 rows in set (0.075 sec)查看这些 tablet 开始保留的时间点。
grep "prepare tablet" observer.log.xxx | grep T1002_PREFETCH_ | grep -E "$id1 | $id2 | ......" observer.log.20250425141928446:[2025-04-25 14:18:50.387192] INFO [STORAGE] prepare_tablet_ (ob_backup_utils.cpp:2122) [401270][T1002_PREFETCH_][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=1] prepare tablet(tenant_id=1002, ls_id={id:1001}, tablet_id={id:1152921504606847694}......其中 1002 替换成对应的
tenant_id，$id1、$id2替换成上一步得到的tablet_id。查看这些 tablet 释放的时间点。
grep -F "[INDEX_BUILDER_MGR] remove sstable index builder" observer.log.xxx | grep T1002_BACKUP_DATA | grep -E "$id1 | $id2 | ......"
根据以上信息，可以判断某一时刻备份大致的磁盘使用量。
预估合并的磁盘占用量
合并的磁盘膨胀可以大致根据宏块重用率、合并时长以及 undo_retention（多版本保留时长）来判断。
查看 top 10 tablet 的宏块重用率。
在
__all_virtual_tablet_compaction_history中仍保留此次合并纪录的情况下，可以查看新生成宏块最多的 10 个 tablet 的宏块重用率。select start_time, finish_time, tablet_id, multiplexed_macro_block_count/macro_block_count * 100 as reused_portion from __all_virtual_tablet_compaction_history where tenant_id = xxx and svr_ip= "xxx" and type like "%MAJOR%" and compaction_scn = xxx order by (macro_block_count-multiplexed_macro_block_count) limit 10; +---------------------+----------------------------+----------------------------+---------------------+----------------+ | compaction_scn | start_time | finish_time | tablet_id | reused_portion | +---------------------+----------------------------+----------------------------+---------------------+----------------+ | 1747651731285499000 | 2025-05-19 18:52:58.941794 | 2025-05-19 18:52:59.352374 | 217749 | 0.0000 | | 1747651731285499000 | 2025-05-19 18:56:42.992081 | 2025-05-19 18:56:43.268980 | 219301 | 98.6486 | | 1747651731285499000 | 2025-05-19 18:56:57.654203 | 2025-05-19 18:56:58.404346 | 1152921504606888312 | 98.5714 | | 1747651731285499000 | 2025-05-19 18:56:58.517974 | 2025-05-19 18:56:58.754112 | 214126 | 100.0000 | | 1747651731285499000 | 2025-05-19 18:57:28.288957 | 2025-05-19 18:57:28.743616 | 209702 | 60.0000 | | 1747651731285499000 | 2025-05-19 18:57:34.432349 | 2025-05-19 18:57:34.667546 | 217470 | 18.1818 | | 1747651731285499000 | 2025-05-19 18:57:40.447015 | 2025-05-19 18:57:41.178206 | 216147 | 0.0000 | | 1747651731285499000 | 2025-05-19 18:57:43.386301 | 2025-05-19 18:57:43.997164 | 219040 | 0.0000 | | 1747651731285499000 | 2025-05-19 18:57:59.521782 | 2025-05-19 18:57:59.821663 | 217464 | 9.5238 | | 1747651731285499000 | 2025-05-19 19:00:18.426821 | 2025-05-19 19:00:18.611409 | 217632 | 63.6364 | +---------------------+----------------------------+----------------------------+---------------------+----------------+undo_retention与合并时长的影响。对于未重用的宏块，合并可能会 Hold 其多版本导致磁盘空间膨胀，膨胀的程度与
undo_rention负相关，与合并时长正相关。
问题原因
备份期间有磁盘膨胀本身是符合预期的，这是因为备份的实现要求能够保留 tablet 的某个老版本的全量数据。 通常情况下，建议备份前做一次全量合并，这样能够减少备份数据量，降低备份的磁盘空间占用。但如果备份和合并并发，那么合并本身由于其保留多版本的需求，反而会导致磁盘占用率进一步上升。
问题的风险及影响
备份期间磁盘占用率较高，进而可能导致备份失败。
适用版本
OceanBase 数据库 V4.x 版本。
解决方法
备份前做一次合并，如果备份并发度（ha_low_thread_score）较大，则适当调小，具体详情参见：ha_low_thread_score。
规避方式
预留足够的磁盘空间，按照上述 预估备份的磁盘占用量 章节的计算方式：需要预留备份占用空间 ≥ 前 N 个最大 tablet 的数据量（N = ha_low_thread_score），如果单个 tablet 大小不足 4GB，则按 4GB 计算；对于合并，无法精确预估磁盘膨胀的空间，只能根据宏块重用率、合并时长以及 undo_rention 定性估计。
