物理备份磁盘膨胀的原因和解决方法

问题现象

备份期间磁盘使用率上升，在磁盘水位线本身已经较高的情况下，可能达到 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 为例）。

   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 开始保留的时间点。

   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 释放的时间点。

   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 的宏块重用率。

   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。

规避方式

预留足够的磁盘空间，按照上述 预估备份的磁盘占用量 章节的计算方式：需要预留备份占用空间 ≥ 前 N 个最大 tablet 的数据量（N = ha_low_thread_score），如果单个 tablet 大小不足 4GB，则按 4GB 计算；对于合并，无法精确预估磁盘膨胀的空间，只能根据宏块重用率、合并时长以及 undo_rention 定性估计。