OceanBase 数据库的 GC 回收处理机制

OceanBase 数据库通过 Partition 管理 MemTable 和 SSTable，无论上述操作执行成功或失败，均可能为系统遗留一些需要回收的资源，因此需要有统一处理这些资源的回收，即 Garbage Collection（下文简称 GC）。

GC 处理对象

OceanBase 数据库中需要回收的分区包括：

• 建表失败遗留的分区

• 执行了 schema_drop 语句的分区

• 迁移失败目标端的分区

• 迁移成功源端的分区

OceanBase 数据库后台存在一个 GC 线程，每隔 10s 会对本机所有分区进行一次遍历，判断哪些需要被回收，并对这些资源执行删除操作。判断 partition 是否可以删除的依据，主要通过检查 member_list、schema 以及副本状态等方式来实现。

GC 处理流程

1. 检查 member_list。

   GC 线程在执行 member_list 检查时，会遍历本机所有副本，并做如下前置检查。

   • 处于分裂状态中的副本不允许 GC

   • 处于成员变更过程中的副本不允许 GC

   • 处于迁移过程中的副本不允许 GC

   • 有未完成迁移任务的副本不允许 GC

   说明

   目前 member_list 的检查有 double check 机制，即连续两次检查通过后才会执行 GC，因此满足 GC 条件的副本会至少延后 10s 删除。

2. 检查 schema。

   GC 线程除检查 member_list 外，还会检查 schema，以处理 DROP TENANT、DROP TABLE 语句等场景。

   • DROP TENANT 语句

     • 默认情况下，由于配置项 schema_history_expire_time 的影响，默认会延迟 7 天删除租户。有关 schema_history_expire_time 的详细信息，请参见《OceanBase 数据库 参考指南》的 配置项 章节。

     • 如果添加了使用了 FORCE 命令，则会立即删除租户的 schema。

     • GC 线程检查到租户被删除后，会立即回收租户的所有分区，该过程不会写入 offline 日志。

   • DROP TABLE 语句：当 GC 线程检查前置条件，如果当前分区的 schema 已经被删除，就会执行如下流程。

     • 对于 leader 副本：

       1. 写 offline 日志（liboblog 依赖 offline 日志来确认日志已经同步），并同步给备机。

       2. 等待 schema 删除超过 30 分钟。

       3. 等待 offline 日志在多数派上写成功（检查多数派的 ilog）。

          说明

          如果集群开启了物理备份（归档），则 OceanBase 数据库会等待 offline 日志归档后才会继续执行后面的 GC 流程。

       4. 从 __all_tenant_gc_partition_info 表中删除该行。

       5. 删除分区。

     • 对于 follower 副本：

       1. 检查 __all_tenant_gc_partition_info 表，确认里面的记录是否已被删除，如果记录还在则跳过该副本。

       2. 如果表中记录已经不在，则删除该副本。