--- title: 物理备份磁盘膨胀的原因和解决方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于物理备份磁盘膨胀的原因和解决方法相关的常见问题和使用技巧，帮助您快速解决物理备份磁盘膨胀的原因和解决方法的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # 物理备份磁盘膨胀的原因和解决方法 更新时间：2026-06-16 09:21 适用版本： V4.0.x、V4.1.x、V4.2.x、V4.3.x 内容类型：Troubleshoot ## 问题现象 备份期间磁盘使用率上升，在磁盘水位线本身已经较高的情况下，可能达到 `data_disk_usage_limit_percentage`（默认 95%）而导致备份因 4184（OB_SERVER_OUTOF_DISK_SPACE）失败。特别地，在备份和合并并发的情况下，磁盘膨胀率可能更高。 ## 关键诊断信息 ### 预估备份的磁盘占用量 对于每个备份线程，大致流程如下： 1. 取一批 tablet_id（最多 2000 个）。 2. 保留这些 tablet 的某个版本的全量数据。 3. 备份这些数据。 4. 释放这些版本，允许其被回收。 为了避免过多占用磁盘，备份还存在如下限制： - 如果这一批 tablet 的数据已经超过了 4GB，则最多只保留 4GB，剩余 tablet 留待下一批处理。 - 如果单个 tablet 的数据超过了 4GB，则本次只保留这一个 tablet。 因此，理论上最坏情况下备份会保留前 N 个最大的 tablet，其中 N 是备份并发度 `ha_low_thread_score`。 以下是进一步确认的方法： 1. **查看前 N 个最大 tablet 的数据量（这里以 N=10 为例）。** ```shell 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) ``` 2. **查看这些 tablet 开始保留的时间点。** ```shell 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`。 3. **查看这些 tablet 释放的时间点。** ```shell grep -F "[INDEX_BUILDER_MGR] remove sstable index builder" observer.log.xxx | grep T1002_BACKUP_DATA | grep -E "$id1 | $id2 | ......" ``` 根据以上信息，可以判断某一时刻备份大致的磁盘使用量。 ### 预估合并的磁盘占用量 合并的磁盘膨胀可以大致根据宏块重用率、合并时长以及 `undo_retention`（多版本保留时长）来判断。 1. **查看 top 10 tablet 的宏块重用率。** 在 `__all_virtual_tablet_compaction_history` 中仍保留此次合并纪录的情况下，可以查看新生成宏块最多的 10 个 tablet 的宏块重用率。 ```shell 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 | +---------------------+----------------------------+----------------------------+---------------------+----------------+ ``` 2. **`undo_retention` 与合并时长的影响。** 对于未重用的宏块，合并可能会 Hold 其多版本导致磁盘空间膨胀，膨胀的程度与 `undo_rention` 负相关，与合并时长正相关。 ## 问题原因 备份期间有磁盘膨胀本身是符合预期的，这是因为备份的实现要求能够保留 tablet 的某个老版本的全量数据。 通常情况下，建议备份前做一次全量合并，这样能够减少备份数据量，降低备份的磁盘空间占用。但如果备份和合并并发，那么合并本身由于其保留多版本的需求，反而会导致磁盘占用率进一步上升。 ## 问题的风险及影响 备份期间磁盘占用率较高，进而可能导致备份失败。 ## 适用版本 OceanBase 数据库 V4.x 版本。 ## 解决方法 备份前做一次合并，如果备份并发度（`ha_low_thread_score`）较大，则适当调小，具体详情参见：[ha_low_thread_score](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002015590)。 ## 规避方式 预留足够的磁盘空间，按照上述 **预估备份的磁盘占用量** 章节的计算方式：**需要预留备份占用空间 ≥ 前 N 个最大 tablet 的数据量（N = ha_low_thread_score），如果单个 tablet 大小不足 4GB，则按 4GB 计算**；对于合并，无法精确预估磁盘膨胀的空间，只能**根据宏块重用率、合并时长以及 `undo_rention` 定性估计**。 上一篇 [tsar 命令不显示 traffic 流量指标问题的原因及解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001885319) 下一篇 [关于 Cache 占用高的说明](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000704209) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线