Question 1

なぜ、SeaweedFS mountにコピーするときに大容量ファイル（>10GB）が破損するのか？

Accepted Answer

これは、SeaweedFSにおいて10GBを超えるファイルを扱う際のチャンクサイズ制限に関する既知の問題です。マウントオプションを使用してより大きなチャンクサイズを設定してください。ファイル20～100GBの場合は`weed mount -chunkSizeLimitMB=8`、100～200GBの場合は`-chunkSizeLimitMB=16`を使用します。これにより、ゼロ埋めブロックやMD5不一致の原因となる内部ブロックの不整合を防ぎます。

Question 2

filer.backup が接続されているときに SeaweedFS filer が CPU コアを1つ完全に消費するのはなぜですか？また、それを修正するにはどうすればよいですか？

Accepted Answer

これは、filerの`SubscribeMetadata`ループにおけるバグです（issue #11635、#11644で修正済み）。`weed filer.backup`クライアントが、ローカルfilerの永続化メタデータログの末尾を超えた開始位置を持つチェックポイントから再開すると（書き込みの少ないクラスターでよく発生します）、filerは一時停止せずに永続化ログを継続的に再読み込みし、新しい書き込みが到着するまで接続ごとに約1 CPUコアを消費し続けます。

回避策（issueで確認済み）：
1. ビジー状態のfilerを通じて、購読対象パス外（例：`/buckets`の外）に任意のファイルを書き込みます。これによりログカーソルが進み、次回のログフラッシュから1分以内にCPUが約1100mから約10mに低下します。
2. ランダムにfilerを選択するheadlessサービスではなく、再開位置より後にエントリが存在する永続化ログを持つfilerに`filer.backup`を向けます。

恒久対策：PR #11644を含むSeaweedFSリリースにアップグレードしてください。これにより、ウェイクアップのたびに再リストするのではなく、実際の変更（ローカルフラッシュ、ピアのウォーターマーク移動、カーソル移動）があった場合のみディスク読み取りパスが実行されるようになります。

Question 3

2つのクラスターで異なる jwt.filer_signing キーを使用している場合、なぜ weed filer.sync はプロキシされたチャンクで 401 Unauthorized エラーにより失敗するのですか？

Accepted Answer

SeaweedFS 4.47 およびそれ以前では、`weed filer.sync` は TLS にのみ `-a.security`/`-b.security` を使用しており、プロキシされたチャンクの読み書き(`?proxyChunkId=`)に署名する JWT は、プロセス全体の `security.toml`(`jwt.filer_signing.key` / `jwt.filer_signing.read.key`)から取得されていました。クラスターごとに異なるキーを使用すると、片方が常に 401 を返します。

修正方法: PR #11645 を含むビルド(4.47 の後、10月8日にマージ)にアップグレードしてください。このビルドでは、`security.LoadFilerJwtFromFile` を介して各側のセキュリティファイルから `jwt.filer_signing.*` を読み込み、側ごとの `security.FilerJwtProvider` を `FilerSource` および `FilerSink`(`UploadOption.FilerJwt`)に渡します。これには `ResolveChunkManifestWithFilerJwt` を介したマニフェストチャンクも含まれ、未設定の場合はグローバルキーにフォールバックします。その後、例えば次のように実行します:

`weed filer.sync -a A:8888 -b B:8888 -a.security a.toml -b.security b.toml -a.filerProxy -b.filerProxy -isActivePassive`

4.47 およびそれ以前での回避策: 両方のクラスターに同一の `jwt.filer_signing` キーを設定し、それらを filer.sync プロセスのグローバル `security.toml` に配置してください。

Question 4

なぜ volume.tier.compact を実行すると、SeaweedFS のボリュームが Read/Write になり、レプリカが out-of-sync になるのですか？

Accepted Answer

これは `volume.tier.compact` における確認済みのバグで、PR #11783（マージ済み）で修正されました。その修正を含むビルドに SeaweedFS をアップグレードしてください。

根本原因：(1) compact コマンドは Unmount + Mount によってリモートオブジェクトをダウンロードしましたが、再マウントされたレプリカは完全に書き込み可能 (ReadOnly=false) な状態で読み込まれ、兄弟レプリカは読み取り専用のままだったため、マスターは新しい書き込みをその 1 つのレプリカにのみ振り分け、不整合が発生しました。(2) Compact は実行対象となったレプリカのみを書き換えました。兄弟レプリカは古い共有リモートオブジェクトを指し示す `.idx`/`.vif` メタデータを保持したままであり、compact がそのリモートオブジェクトを削除したため、兄弟レプリカには陳腐化したメタデータが残されました。

この修正は、compact+resync サイクル全体にわたってすべてのレプリカを読み取り専用に固定し、更新された `.idx`/`.vif` をすべての兄弟レプリカへ再同期することで、クラウドティアリングされたボリュームを一貫して読み取り専用に保ちます（S3 が部分書き込みをサポートしないため必須）。

Question 5

SQL filer ストアを使用しているときにプレフィックスにアンダースコアが含まれると、なぜ SeaweedFS の S3 ListObjects は誤った結果を返し、動作が遅くなるのですか？

Accepted Answer

SQL filer ストア (mysql, mysql2, postgres, postgres2, sqlite) は、`weed/filer/abstract_sql/abstract_sql_store.go` (約405行目) において、ListObjects のプレフィックスをエスケープしないまま SQL の `LIKE` 句に渡しているため、プレフィックス内の `_` と `%` がワイルドカードとして機能します。これにより `(dirhash, name)` 主キーのレンジスキャンが拡大し、インデックスの張られていない `directory` カラムへの行ルックアップが強制され、誤ったマッチと約40倍のクエリ低速化の両方が引き起こされます。修正方法: `%` を追加する前にプレフィックス内の `\`、`%`、`_` をエスケープし、明示的な `ESCAPE '\'` 句を追加して、MySQL/OceanBase と Postgres で動作が同一になるようにします:
```go
escapedPrefix := strings.NewReplacer(
    `\`, `\`,
    `%`, `\%`,
    `_`, `\_`,
).Replace(prefix)
// bind escapedPrefix+"%" to the LIKE parameter
```
また、同一のバグを持つ `ForceBinaryCollation` (`BINARY name`) のコードパスにも同じエスケープを適用してください。パッチが適用されるまでの回避策: プレフィックスを文字どおりに比較するため影響を受けない、非 SQL filer バックエンド (leveldb, rocksdb, redis) を使用してください。

SeaweedFS

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト