OceanBase 数据库通过 Partition 管理 MemTable 和 SSTable，无论上述操作执行成功或失败，均可能为系统遗留一些需要回收的资源，因此需要有统一处理这些资源的回收，即 Garbage Collection（下文简称 GC）。
GC 处理对象
OceanBase 数据库中需要回收的分区包括：
- 建表失败遗留的分区
- 执行了 schema_drop 语句的分区
- 迁移失败目标端的分区
- 迁移成功源端的分区
OceanBase 数据库后台存在一个 GC 线程，每隔 20s 会对本机所有分区进行一次遍历，判断哪些需要被回收，并对这些资源执行删除操作。判断 partition 是否可以删除的依据，主要通过检查 member_list、schema 以及副本状态等方式来实现。
GC 处理流程
- 检查 member_list。
- GC 线程在执行 member_list 检查时，会遍历本机所有副本，并做如下前置检查：
- 处于分裂状态中的副本不允许 GC
- 处于成员变更过程中的副本不允许 GC
- 处于迁移过程中的副本不允许 GC
- 有未完成迁移任务的副本不允许 GC
- 说明目前 member_list 的检查有 double check 机制，即连续两次检查通过后才会执行 GC，因此因此满足 GC 条件的副本会至少延后 10s 删除。
- 检查 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 副本：
- 写 offline 日志（liboblog 依赖 offline 日志来确认日志已经同步），并同步给备机。
- 等待 schema 删除超过 30 分钟。
- 等待 offline 日志在多数派上写成功（检查多数派的 ilog）。
- 说明如果集群开启了物理备份（归档），则 OceanBase 数据库会等待 offline 日志归档后才会继续执行后面的 GC 流程。
- 从 __all_tenant_gc_partition_info 表中删除该行。
- 删除分区。
- 对于 follower 副本：
- 检查 __all_tenant_gc_partition_info 表，确认里面的记录是否已被删除，如果记录还在则跳过该副本。
- 如果表中记录已经不在，则删除该副本。