Apache Doris Trash与Recover机制

​一、核心概念与架构

1. ​回收站（Catalog Recycle Bin）​

• 存储逻辑元数据：保存被删除的库/表/分区/物化视图的元数据信息
• 恢复入口点：通过RECOVER命令恢复数据
• 默认保留时间：catalog_trash_expire_seconds（默认1天，86400秒）

2. ​物理垃圾（BE Trash）​

• 存储物理数据文件：存放已删除数据文件、临时文件、ETL中间文件
• 文件类型：.trash目录下的Segment文件、倒排索引文件等
• 自动清理周期：trash_file_expire_time_sec（默认1小时，3600秒）

3. ​关键路径：

markdown
复制
BE节点路径：
/data/doris/storage/trash/{timestamp}  
FE元数据路径：
fe_meta/catalog_recycle_bin.db

​二、核心工作流程

graph TD
    A[用户执行DROP/TRUNCATE操作] --> B{是否FORCE?}
    B -->|是| C[直接删除元数据+物理文件]
    B -->|否| D[元数据写入Catalog Recycle Bin]
    D --> E[物理文件移动到BE Trash目录]
    E --> F[FE后台任务]
    F --> G{检查catalog_trash_expire_seconds}
    G -->|元数据过期| H[删除Catalog Recycle Bin记录]
    G -->|未过期| I[保留元数据]
    E --> J[BE后台任务]
    J --> K{检查trash_file_expire_time_sec}
    K -->|物理文件过期| L[删除.trash目录文件]
    K -->|未过期| M[保留物理文件]
    H --> N[元数据消失后无法RECOVER]
    L --> O[物理文件消失后无法RECOVER]

​三、核心控制参数

参数名	作用域	默认值	说明
catalog_trash_expire_seconds	FE	86400	元数据在回收站的保留时间（秒）
enable_trash	BE	true	是否启用Trash机制
trash_file_expire_time_sec	BE	3600	物理文件在Trash目录的保留时间
trash_check_interval_seconds	BE	600	垃圾文件检查间隔

​四、运维SQL全集

1. ​删除操作

sql
复制
-- 强制删除（绕过回收站）
TRUNCATE TABLE db.table PARTITION(partition_name) FORCE;
ALTER TABLE db.table DROP PARTITION partition_name FORCE;

2. ​恢复操作

sql
复制
-- 查看可恢复对象
SHOW CATALOG RECYCLE BIN; 

-- 恢复指定表（自动重建元数据+物理文件）
RECOVER TABLE db.table FROM RECYCLEBIN;

-- 恢复指定分区
RECOVER PARTITION "p202301" FROM TABLE db.table;

3. ​空间管理

sql
复制
-- 查看所有BE的Trash空间
SHOW TRASH; 

-- 查看指定BE的详细磁盘占用
SHOW TRASH ON "be_host:9050";

-- 立即清理所有Trash文件
ADMIN CLEAN TRASH;

-- 清理指定BE的Trash
ADMIN CLEAN TRASH ON "be_host:9050";

​五、日常运维场景

场景1：误删恢复

sql
复制
-- Step1 确认可恢复对象
SHOW CATALOG RECYCLE BIN 
WHERE NAME LIKE '%table_name%';

-- Step2 执行恢复（需原表结构存在）
RECOVER TABLE db.table FROM RECYCLEBIN;

-- Step3 验证数据
SELECT COUNT(*) FROM db.table;

场景2：空间紧急清理

bash
复制
# 通过MySQL客户端连接
mysql> ADMIN CLEAN TRASH ON "be01:9050";  # 优先清理大节点
mysql> SHOW TRASH;  # 确认清理结果

场景3：长期保留策略调整

sql
复制
-- 修改元数据保留时间（需FE重启）
SET GLOBAL catalog_trash_expire_seconds = 172800;

-- 修改物理文件保留时间（BE动态生效）
curl -X POST http://be_host:8040/api/update_config?trash_file_expire_time_sec=7200

​六、常见问题排查

问题1：RECOVER失败

• 现象：ERROR 2003 (HY000): Cannot recover table, metadata not found

• 检查项：

  1. 确认SHOW CATALOG RECYCLE BIN存在该记录
  2. 检查catalog_trash_expire_seconds是否超时
  3. 确认原表结构未被删除

问题2：Trash空间未释放

• 现象：DISK_USAGE超过85%告警
• 排查步骤：

sql
复制
-- 确认BE实际占用
SHOW TRASH ON "be_host:9050";

-- 检查后台任务
SHOW BACKENDS\G
查看LastTrashCleanTime时间戳

-- 手动触发清理
ADMIN CLEAN TRASH ON "be_host:9050";

问题3：跨节点恢复异常

• 现象：恢复后数据不一致

• 处理方案：

  1. 检查所有BE节点trash_check_interval_seconds一致性
  2. 确认集群时钟同步（NTP服务状态）
  3. 执行强制校验：

sql
复制
ADMIN CHECK TABLE db.table;

​七、最佳实践

1. ​容量规划

• 预留20%磁盘空间应对Trash波动
• 设置/data独立分区避免根目录写满

2. ​监控模板

bash
复制
# Trash空间占比公式
(SUM(TrashUsed) / SUM(DataDirCapacity)) * 100 

# 关键监控项
- BE节点：trash_file_count
- FE：catalog_recycle_bin_item_count

3. ​防御性策略

sql
复制
-- 禁止立即删除
SET GLOBAL enable_force_drop = false;

-- 设置分级保留策略
-- 核心表: 保留7天
ALTER TABLE important_table SET ("catalog_trash_expire_seconds" = "604800");

4. ​自动化清理脚本

bash
复制
#!/bin/bash
# 每日凌晨清理过期Trash
mysql -hfe_host -P9030 -uroot -e "ADMIN CLEAN TRASH" 

​八、底层原理进阶

1. ​文件存储结构

markdown
复制
└── trash
    └── 20231010120000  # 删除时间戳
        ├── 10005  # Tablet ID
        │   └── 123456789.suffix  # Segment文件
        └── 10006
            ├── 987654321.index
            └── 987654321.data

2. ​多版本控制

• 采用<timestamp>_<uuid>目录结构防止命名冲突
• 使用rocksdb记录有效文件清单

3. ​清理触发机制

c
复制
// BE源码片段
void StorageEngine::start_trash_sweep() {
    if (UnixSeconds() - last_clean > _trash_interval) {
        for (auto& path : store_paths) {
            clean_trash(path); 
        }
    }
}