物理恢复过程中因 BACKUP_INDEX_CACHE 缓存未命中导致性能下降问题

问题现象

在执行物理恢复操作时，恢复过程显著变慢。用户在恢复备份数据时，系统频繁访问远端备份介质，触发大量小 I/O 操作，导致整体恢复耗时大幅增加。该现象在使用对象存储作为备份介质时尤为明显，性能远低于使用 NFS 等具备本地缓存能力的存储介质。通过对比不同备份介质恢复耗时可以直观发现问题。

关键诊断信息

触发条件

OceanBase 内核 BUG，导致物理恢复过程中索引缓存维护逻辑异常。

事前巡检

在恢复操作前确认 OBServer 版本是否属于已知问题影响版本。

事后诊断

可通过以下方式快速确认是否命中该问题：

• 查看恢复相关日志，发现频繁的小块数据读取行为。

• 相较使用 NFS 等具备本地缓存机制的恢复介质，对象存储恢复性能明显下降。

• 恢复耗时显著高于预期，且恢复线程 CPU 利用率较低。

• 执行如下 SQL 查询 __all_virtual_kvcache_info，观察 total_put_count 是否异常增高。

  SELECT * FROM oceanbase.__all_virtual_kvcache_info WHERE cache_name = 'BACKUP_INDEX_CACHE' AND tenant_id = $tenant_id;
  

问题原因

本问题源于 OceanBase 内核中的缓存维护逻辑缺陷，具体表现如下：

• 在物理恢复过程中，未能正确维护或命中备份索引缓存。

• 导致系统需反复访问远程备份介质获取元数据或数据块。

• 每次读取数据块大小较小，形成大量小 I/O 请求，严重拖慢恢复进度。

问题的风险及影响

• 触发概率： 必现（在符合触发条件的恢复操作中稳定复现）。

• 影响范围： 所有执行物理恢复操作的场景，尤其使用对象存储作为备份介质的用户。

• 业务风险：

  • 恢复时间大幅延长，影响系统 RTO。

  • 恢复期间资源占用异常，可能影响其他业务并发。

  • 恢复窗口扩大，增加宕机恢复的不可控风险。

影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

影响版本

OceanBase 数据库企业版 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。

解决方法

遇到此问题后，可使用以下方式进行应急处理：

• 增大恢复并发度配置参数 ha_high_thread_score，提高恢复线程数量。

• 通过增加并发缓解单线程小 I/O 瓶颈，提高数据拉取效率。

规避方式

为了避免再次触发该问题，建议用户和运维人员采取以下手段：

• 备份介质选择： 优先使用 NFS 等具备本地缓存能力的高性能存储作为备份介质。

• 恢复参数优化： 提前配置合理的恢复并发参数，提高恢复时的执行效率。

• 恢复前预评估： 恢复前对备份存储性能进行评估，避免在低吞吐对象存储环境中发起大规模恢复操作。

• 版本更新： 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5 BP5（oceanbase-4.2.5.5-105000052025070822）及之后版本、V4.3.4 GA（oceanbase-4.3.4.0-100000132024103017）及之后版本。