ClickHouse Operator 中 S3 存储表缩容时的数据清理问题分析

问题背景

在使用 ClickHouse Operator 管理 Kubernetes 上的 ClickHouse 集群时，当集群缩容（减少副本数）且表使用 S3 存储时，会出现 S3 存储桶中遗留孤立文件的问题。这一问题不仅影响存储空间的有效利用，还可能导致数据不一致和潜在的安全风险。

问题现象

当执行以下操作序列时，可以重现该问题：

1. 创建包含 2 个副本的 ClickHouse 集群，配置使用 S3 存储策略
2. 创建使用 S3 存储的复制表并插入数据
3. 将副本数从 2 缩减为 1
4. 在剩余副本上删除表后，S3 存储桶中仍保留部分文件

测试环境使用 ClickHouse 24.3.2.3 和 clickhouse-operator 0.23.3 版本。

技术分析

根本原因

ClickHouse Operator 在处理缩容操作时，仅对 ReplicatedMergeTree 表、复制数据库、视图和字典执行清理操作。对于普通 MergeTree 表或 S3 存储的表，清理逻辑不完整，导致：

1. 缩容时未同步删除 S3 上的数据文件
2. 表删除操作可能异步执行，在操作完成前 Pod 已被终止
3. 零拷贝复制和非零拷贝复制模式下都存在此问题

影响范围

该问题影响所有使用 S3 存储的 MergeTree 系列表，包括：

• 直接使用 S3 存储策略的表
• 使用 S3 磁盘配置的表
• 零拷贝和非零拷贝复制模式下的表

解决方案

临时解决方案

在缩容前，手动连接到将被移除的副本节点，执行显式的表删除操作：

DROP TABLE table_name SYNC;

使用 SYNC 关键字可确保表数据被同步删除，包括 S3 上的存储文件。

长期解决方案

ClickHouse Operator 在 0.24.0 版本中修复了此问题，改进内容包括：

1. 完善了表删除逻辑，确保所有表类型都能被正确清理
2. 增加了对 S3 存储文件的清理检查
3. 优化了缩容时的资源回收流程

建议用户升级到 0.23.7 或更高版本以获得修复。

最佳实践

1. 升级策略：定期升级 ClickHouse Operator 以获取最新的稳定性修复
2. 缩容操作：在缩容前执行数据验证和清理检查
3. 监控配置：设置对 S3 存储桶的监控，及时发现孤立文件
4. 测试验证：在生产环境变更前，在测试环境验证缩容操作的数据清理效果

结论

ClickHouse Operator 的 S3 存储清理问题在较新版本中已得到修复。用户应当注意升级操作并遵循推荐的缩容流程，以确保数据的一致性和存储资源的有效利用。对于关键生产环境，建议在变更窗口执行缩容操作，并提前验证数据清理效果。