延迟删除异常导致节点冗余副本增长或 server_event_history 大量膨胀问题分析

问题现象

在集群表数量多、大量分区需延迟删除的场景下，出现延迟删除任务未执行，导致大量已删除表的分区长期未被物理回收，分区数持续增长，存在单节点分区数达到上限的风险。用户观察到存在以 DELAY_DELETE 开头的表，且 __all_tenant_gc_partition_info 表为空，但延迟删除任务未触发，无相关日志输出。同时可能观察到 __all_server_event_history 中 GC 模块 event = 'gc_candidates' 的事件大量膨胀。

关键诊断信息

触发条件

• 集群表数量多、大量分区需延迟删除。
• SYS 租户内存较小，导致 schema cache 被挤占，后台表组自检任务执行缓慢（问题集群 SYS 租户内存低于正常集群，16G vs 30G）。

事前巡检

• 避免 SYS 租户内存配置过低，尤其在表数量多、DDL 频繁的场景下。
• 存在冗余副本时，定期监控 __all_rootservice_event_history 中 event = 'force_drop_schema' 的事件，确认延迟删除任务正常运行；同时监控延迟删除任务日志，及时发现延迟删除异常。
• 在集群表数量较多或频繁执行 DDL 操作前，提前评估 SYS 租户资源是否充足。

事后诊断

• 查询主库待延迟删除的冗余副本数量：

select count(*) from __all_virtual_clog_stat where table_id in (select table_id from __all_virtual_table_history where drop_schema_version > 0);

• 内部表 __all_rootservice_event_history 中长期没有 event = 'force_drop_schema' 事件，表明任务未被成功调度或执行。
• __all_tenant_gc_partition_info 表为空，说明系统未记录待回收的分区信息，但实际存在延迟删除的表。
• drop_schema_version > 0 且 reserved_schema_version = 0，满足延迟删除条件。
• 表组自检任务执行缓慢，说明瓶颈在于资源不足导致的性能下降。

问题原因

该问题为 OceanBase 内核已知 BUG，属于 3.x 版本延迟删除机制的缺陷场景。当集群表数量过多、大量分区需延迟删除，且 SYS 租户内存较小导致 schema cache 被挤占时，后台表组自检任务执行缓慢，阻塞了延迟删除任务的调度队列；一旦某次调度失败，后续任务无法被重新加入队列，导致任务丢失，延迟删除彻底失效，造成冗余分区持续堆积。大量分区等待物理回收时持续产生 GC 事件，导致 __all_server_event_history 表大量膨胀。

问题的风险及影响

单节点冗余副本持续增长，可能达到单节点分区数上限，引发写入失败或集群稳定性风险；__all_server_event_history 不断膨胀影响存储资源利用率，增加运维管理复杂度。

影响租户

影响版本

解决方法

1. 调大 SYS 租户内存，确保 schema cache 有足够的空间，使表组自检任务能正常执行，从而恢复延迟删除任务的调度（会导致备库不同步）。
2. 若无法调大内存，可手动执行应急方案（会导致备库不同步）：
   1. 在 sys 租户下执行错误注入命令，阻塞表组自检：alter system set_tp tp_no = 104, error_code = 4016, frequency = 1;
   2. 切换 RS（RootService）。
   3. 预期 10 分钟左右，观察如下 SQL 有新增返回，证明 GC 任务开始执行：select * from __all_rootservice_event_history where event = 'force_drop_schema' order by gmt_create desc limit 20;
   4. 监控待 GC 分区数，需要等待至少 30 分钟以上才会减少：select count(*) from __all_virtual_clog_stat where table_id in (select table_id from __all_virtual_table_history where drop_schema_version > 0);
   5. 待延迟删除分区清空后，回滚错误注入命令：alter system set_tp tp_no = 104, error_code = 4016, frequency = 0;
3. 建议在恢复后重建备库，以确保主备数据一致性，避免因延迟删除恢复导致备库不同步问题。

规避方式

1. 避免 SYS 租户内存配置过低，尤其在表数量多、DDL 频繁的场景下。
2. 存在冗余副本时，定期监控 __all_rootservice_event_history 中 event = 'force_drop_schema' 的事件，确认正常运行；监控延迟删除任务日志，及时发现延迟删除异常。
3. 在集群表数量较多或频繁执行 DDL 操作前，提前评估 SYS 租户资源是否充足。