Question 1

なぜRustFSは、クライアントリクエストのないアイドル状態のクラスタでも、継続的なネットワークトラフィックとCPU負荷を生成するのですか？

Accepted Answer

これはティアのフリーバージョン復旧スキャナーが原因です。リモートティアが設定されていない場合でも（admin/v3/tier が [] を返す場合でも）、選出された復旧リーダーはルートからすべてのバケットを再帰的に走査し、すべてのピアから xl.meta（インラインオブジェクトデータを含む）をストリーミングします。症状: リーダーノードはピアから 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

リーダーノードでの測定結果: 受信トラフィックは 9.3 MB/s から 0.28 MB/s に低下し、rustfs の CPU は 0.77 コアから 0.05 コアに低下しました。注意: RUSTFS_HEAL_OBJECT_SELECT_PROB=0 はヒーリングにのみ影響するため、この負荷は止まりません。フリーバージョンはリモートティアなしでは存在し得ないため、実際にリモートティアを設定する場合にのみスイープを再度有効にしてください。

Question 2

RustFSでS3バケットポリシーを適用する際に発生する "invalid key name: 's3:ObjectCreationOperation'" エラーを修正する方法

Accepted Answer

このエラーは、PR #8671 より前のバージョンの RustFS が AWS 条件キー `s3:ObjectCreationOperation` を認識しないために発生します。そのため、このキーを含むポリシーはすべて解析に失敗します。PR #8671 を含むビルドに RustFS をアップグレードしてください。この 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

根本原因: 明示的な `VersionId` を指定して **削除マーカー** を対象とした `DeleteObjects` が、その削除をバージョンの削除ではなくマーカーの書き込みとして扱うバグ。API は成功を返すものの、マーカーは残存します。削除マーカーはコンテンツとしてカウントされるため、`DeleteBucket` は `The bucket you tried to delete is not empty` で失敗します。このバグは、(a) 1 つのバッチに同じキーの複数の削除マーカーバージョンが含まれる場合（2 つ目以降のマーカーは暗黙的にスキップされる）、または (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 マッチング（PreconditionFailed）による S3 の条件付き削除をサポートしていますか？

Accepted Answer

はい、S3 DeleteObjects API向けのETagベースの条件付き一括削除が実装され、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カタログ v1.0.1-preview.5 におけるサーバーサイドのバグで、rewrite_manifests コミットを誤って行レベル操作として検証し、拒否してしまいます。修正方法: カタログサーバーを 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 のままにしてください。代替案として、このコミット検証バグのない Lakekeeper など、別の RESTカタログ実装を使用してください。

rustfs

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト