Question 1

为什么在没有客户端请求的情况下，RustFS 会在空闲集群上产生持续的网络流量和 CPU 负载？

Accepted Answer

这是由 tier 空闲版本恢复扫描器引起的：即使没有配置任何远程 tier（`admin/v3/tier` 返回 `[]`），当选的恢复 leader 仍会从根目录递归遍历每个存储桶，并从所有 peer 节点流式传输 `xl.meta`（包括内联对象数据）。症状表现为：leader 节点从 peer 节点接收 10-15 MB/s 的流量，并占用约 1 个 CPU 核心，且针对每个存储桶反复发起 `GET /rustfs/rpc/walk_dir` 调用（`recursive: true`，`base_dir: ""`）。该负载跟随 `tier-free-version-recovery/leader.lock` 选举，并在 pod 重启后转移到另一个节点。

解决方法（已在 RustFS 1.0.3 上验证）：通过设置以下环境变量禁用恢复扫描：

```
RUSTFS_TIER_FREE_VERSION_RECOVERY_ENABLED=false
```

在 leader 节点上的实测结果：入站流量从 9.3 MB/s 降至 0.28 MB/s，rustfs CPU 占用从 0.77 降至 0.05 核心。注意：`RUSTFS_HEAL_OBJECT_SELECT_PROB=0` 并不能阻止该负载，因为它只影响修复（healing）。只有在您实际配置了远程 tier 的情况下才应重新启用该扫描，因为没有远程 tier 就不可能存在空闲版本。

Question 2

如何修复在 RustFS 中应用 S3 存储桶策略时出现的 "invalid key name: 's3:ObjectCreationOperation'" 错误？

Accepted Answer

此错误的原因是 PR #8671 之前的 RustFS 版本无法识别 AWS 条件键 `s3:ObjectCreationOperation`，因此任何包含该键的策略都会解析失败。请将 RustFS 升级到包含 PR #8671 的构建版本，该 PR 会在每次 `s3:PutObject` 授权时将此键作为服务器派生的 Bool 值添加：对于分段上传的暂存操作（CreateMultipartUpload、UploadPart、UploadPartCopy）为 `false`，对于实际的对象写入（PutObject、CopyObject、CompleteMultipartUpload、POST Object）为 `true`。由于该值是服务器派生的，任何请求头或身份声明都无法提供或覆盖它。升级后，您可以使用 AWS 文档中记录的策略结构来强制执行条件写入（`If-None-Match: *`，即仅创建、不覆盖），同时仍允许分段上传：

[
  {
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::bucket/*",
    "Condition": { "Null": { "s3:if-none-match": "false" } }
  },
  {
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::bucket/*",
    "Condition": { "Bool": { "s3:ObjectCreationOperation": "false" } }
  }
]

注意：完整的条件写入示例还需要 `s3:if-none-match` 条件键，该键通过 PR #8615 单独添加。

Question 3

为什么在对启用了版本控制的存储桶成功执行 Multi-Object Delete (DeleteObjects) 之后，DeleteBucket 仍会因 BucketNotEmpty 错误而失败？

Accepted Answer

根本原因:一个 bug——当 `DeleteObjects` 携带显式 `VersionId` 且目标为**删除标记(delete marker)**时,该移除操作被当作标记写入而非版本删除来处理。API 返回成功,但该标记仍然存在——而删除标记会被计为内容,因此 `DeleteBucket` 失败并报错 `The bucket you tried to delete is not empty`。该 bug 在以下情况下触发:(a) 单个批次中包含同一键(key)的多个删除标记版本(第一个之后的标记会被静默跳过),或 (b) 待处理的版本删除复制使标记保留在源端。

**修复:**升级到包含 PR #8854 的 RustFS 构建版本,该 PR 按照 AWS S3 `DeleteObjects` 规范,将显式标记 `VersionId` 的移除请求路由至正常的版本删除路径。回归测试(立即列出 + 删除桶、重复 ID、崩溃恢复)在修复后全部通过。

**未打补丁版本上的变通方法:**
1. 重新发送删除请求:携带标记的 `VersionId` 重试 `POST /bucket?delete`,或发起单独的 `DELETE /bucket/object?versionId=<marker-id>` 请求。
2. 轮询 `ListObjectVersions`,直到不再存在删除标记(由于异步清理,标记可能会在延迟一段时间后消失),然后调用 `DeleteBucket`。
3. 避免在同一批次中包含同一键的重复删除标记版本——将它们拆分为独立的 `DeleteObjects` 调用。
4. 在复制部署环境中,等待版本删除复制完成后再删除桶。

Question 4

DeleteObjects 是否支持带逐对象 ETag 匹配的 S3 条件删除（PreconditionFailed）？

Accepted Answer

是的，基于 ETag 的条件批量删除功能（针对 S3 DeleteObjects API）已实现，并于 10 月 15 日通过 PR #8535 合并到了 main 分支。但是，该功能并未包含在 1.0.4 稳定版中，因为该版本并不包含 main 分支的所有更改。如需现在使用，请从 main 分支构建或部署。维护者计划在经过一轮测试后，于下一个稳定版（1.0.4 之后的版本）中发布该功能。该功能可用后，仅当对象的 ETag 符合条件时才会被删除；否则 API 将返回 PreconditionFailed，这与 AWS S3 的条件删除行为一致，并支持安全的并发删除。

Question 5

如何修复通过 REST catalog 运行 Iceberg rewrite_manifests 时出现的 'row-level snapshot operation requires deleted data files or added delete files' 错误？

Accepted Answer

这是 REST catalog v1.0.1-preview.5 中的一个服务端缺陷，它错误地将 rewrite_manifests 提交按行级操作进行验证并予以拒绝。修复方法：将 catalog 服务器升级到 v1.0.2，在该版本中 `CALL catalog.system.rewrite_manifests(table => 'db.table')` 可以成功执行。请避免使用 v1.0.3——一个回归问题会导致 rewrite_manifests 再次失败，报错 'manifest referenced data file is missing'，即使数据没有任何变更；如果你依赖此过程，请停留在 v1.0.2。作为替代方案，可以使用其他 REST catalog 实现，例如 Lakekeeper，它不存在此提交验证缺陷。

rustfs

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐