mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-06 12:09:12 +00:00
chore: merge ODM bucket incarnation safeguards from main
This commit is contained in:
@@ -87,6 +87,12 @@ The guard requires the documents and section headings listed in its `require_sou
|
||||
|
||||
## On-Demand Migration Service
|
||||
|
||||
Read-through, backfill and external pull orchestration belong in an application
|
||||
service under `rustfs/src/<service>/`. ECStore owns the storage primitives they
|
||||
need, including atomic commits, lifecycle locks and on-disk metadata. A service
|
||||
may use these primitives without moving its provider clients or scheduling
|
||||
policy into the engine.
|
||||
|
||||
`rustfs/src/on_demand_migration/` owns source clients, pull scheduling, list
|
||||
merging, runtime state and backfill orchestration. Its `storage_api.rs` is the
|
||||
only ECStore facade boundary. Object write-back still enters the application's
|
||||
@@ -101,6 +107,13 @@ deployment constraints in the admin use case before the incarnation-fenced
|
||||
metadata update. Backfill reads metadata from its store's instance context and
|
||||
preserves the checkpoint ETag compare-and-set, lease and tail-drained writes.
|
||||
|
||||
An ODM runtime is bound to the bucket incarnation published with its metadata,
|
||||
not just its name. Source reads and write-back reject a different incarnation.
|
||||
Checkpoint writes hold the user bucket's lifecycle fence through their complete
|
||||
commit and read-back, even if their caller stops waiting; the storage commit
|
||||
also observes lock loss. Deleting and recreating a bucket must not let work for
|
||||
its previous incarnation repopulate objects or checkpoints.
|
||||
|
||||
Observability owns its metric DTOs and accepts application snapshot callbacks;
|
||||
it does not depend on the ODM runtime. The application registers both bucket
|
||||
and backfill snapshots during startup, before metadata and metric collection.
|
||||
|
||||
@@ -12,7 +12,7 @@ To inspect readable configurations while identifying failures, use the same auth
|
||||
|
||||
## Recover unreadable replication targets
|
||||
|
||||
MinIO target configuration may be an array or KMS-encrypted data that RustFS cannot decode. Diagnosis preserves the failure instead of interpreting it as an empty target set.
|
||||
RustFS currently accepts the documented `{"targets": [...]}` object format. It cannot decrypt MinIO KMS-encrypted target metadata. Unreadable target payloads remain failures instead of being interpreted as an empty target set; diagnostic export and replacement import do not add MinIO KMS decryption support.
|
||||
|
||||
1. Inspect the diagnostic manifest to identify affected buckets. Preserve a separate backup of the original source configuration and any credentials needed for recovery.
|
||||
2. Prepare a ZIP containing `<bucket>/bucket-targets.json` with a valid RustFS replacement, whose top-level shape is `{"targets": [...]}`. Supply the intended target settings and credentials; exported credentials are redacted. Use `{"targets": []}` only when intentionally clearing all targets, and reconcile any replication rules that reference removed targets.
|
||||
|
||||
Reference in New Issue
Block a user