归档介质满，归档占用 500 租户内存持续升高

问题现象

归档介质出现长时间盘满，并且 OceanBase 数据库 clog 已经回收，同时有新建分区或者分区切主。会出现归档使用用于任务归档的内存占用持续无法释放并且逐渐累积（累积速度与分区数量有关，如有几万个分区，一天增长约 1G）。

关键诊断信息

触发条件

归档介质出现长时间盘满，并且 OceanBase 数据库 clog 已经回收，同时有新建分区或者分区切主。

问题原因

1. 归档由分区 Leader 进行，后台线程周期性（30s 一次）扫描所有分区，对于分区切主或者新建分区，会创建一个 add_task 的任务，调度分区角色为 Leader，但是还未在该 OBServer 执行归档的分区进行归档。

2. 当 NFS（网络文件系统）盘满后，由于归档无法再进行，如果归档模式为 Optional（默认模式），clog 会回收而不考虑归档进度；此时处理 add_task 获取该分区在其他 OBServer 已经归档的进度，并且定位该进度所处 ilog 文件并继续从此归档。

3. 但是在步骤 2 由于 OBServer 日志已经回收，该 add_task 会处理失败并丢回队列尾重试，并且上报 RS 归档断流。

4. 由于此时归档介质满，RS 在归档断流的状态持久化到归档介质可能会失败，RS 的归档状态无法置为 Interrupt（依然为 Doing），OBServer 无法刷新到 Interrupt 误认为归档依然正常，后台扫描线程依然会 30s 扫描一次分区，将分区角色为 Leader 但是并未在该 OBServer 执行归档的分区添加 add_task 任务，该任务占用 500 租户内存，并且由于开启归档失败持续无法释放而累积。

问题的风险及影响

由于用于开启归档的 add_task 仅几十个字节，短时间内归档介质满不会对 OceanBase 产生影响。如果长时间归档盘满，会造成 500 租户内存持续占用上升并影响 OceanBase 数据库稳定运行。

影响租户

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

影响版本

OceanBase 数据库 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V2.2.77 BP19（oceanbase-2.2.77-119000122024060513）及之后版本、V3.2.3 BP9（oceanbase-3.2.3.3-109000182023071410）及之后版本、V3.2.4 BP5（oceanbase-3.2.4.5-105000012023081513）及之后版本。

• 解决 NFS（网络文件系统）盘满问题，或者重启 OBServer 释放内存。

规避方式

1. 监控归档状态，保证归档不落后（V3.x 以及之前版本根据负载等情况，落后告警阈值通常为 15-30 分钟）。

2. 监控归档盘使用状况，保证不出现归档盘满，一旦出现需要人工介入（盘扩容或者暂时关闭归档）。