Thanos Compactor 删除延迟机制解析与优化实践

问题背景

在使用Thanos Compactor组件(v0.35.0版本)进行长期存储管理时，发现一个现象：虽然日志显示Compactor已经执行了标记删除操作，但实际存储中的块数据并未被真正删除。只有当手动使用thanos tools bucket cleanup命令时，这些标记为删除的块才会被清理。

核心机制分析

删除延迟保护机制

Thanos Compactor设计了一个重要的安全机制——删除延迟(delete-delay)。这个机制默认设置为48小时，主要目的是：

1. 防止误删除：为操作人员提供足够的时间窗口来恢复意外标记为删除的数据块
2. 确保数据一致性：在分布式环境下，确保所有组件都能感知到块删除状态的变化
3. 处理网络分区：在网络不稳定的情况下，避免数据被过早删除

删除流程详解

完整的删除流程包含以下阶段：

1. 标记阶段：Compactor根据保留策略将符合条件的块标记为删除(创建deletion-mark.json文件)
2. 延迟等待：等待配置的delete-delay时间(默认48小时)
3. 实际删除：Compactor在后续周期中检查标记时间，超过延迟时间的块才会被物理删除

问题定位与解决方案

问题根源

通过日志分析发现，Compactor确实执行了标记操作，但后续的清理阶段并未实际删除数据。这是因为：

1. 默认的delete-delay=48h设置较长
2. Compactor运行周期内，标记的块尚未达到删除延迟时间阈值

优化方案

根据实际业务需求，可以调整以下参数：

1. 降低删除延迟：对于测试环境或数据安全性要求不高的场景，可以设置为更短时间

   --delete-delay=4h
   

2. 权衡考虑：

   • 生产环境建议保持至少12-24小时的延迟
   • 开发/测试环境可设置为1-4小时
   • 紧急清理时可临时设置为0(不推荐生产环境使用)

最佳实践建议

1. 监控标记块数量：定期检查标记为删除但尚未清理的块数量
2. 合理设置保留策略：确保retention.resolution-*参数与业务需求匹配
3. 版本升级注意：不同Thanos版本可能有不同的默认值，升级时需检查
4. 紧急处理流程：对于存储空间紧急情况，可使用thanos tools bucket cleanup命令立即清理

总结

Thanos Compactor的删除延迟机制是数据安全的重要保障。理解这一机制后，运维人员可以根据实际业务场景灵活调整delete-delay参数，在数据安全性和存储效率之间取得平衡。对于大多数生产环境，建议保持适中的删除延迟(12-24小时)，既能防止误删除，又能确保存储空间得到及时释放。