astelm/minio
1
0
Fork 0
mirror of https://github.com/pgsty/minio.git synced 2026-11-10 17:45:32 +03:00
Code Issues Packages Projects Releases Wiki Activity

fix(ilm): do not replicate deletes that lifecycle makes

Browse Source 
The migration follow-up for #265 (PR #276) made lifecycle-created
deletes replication-aware: the scanner, the expiry of a transitioned
version and the bulk noncurrent purge evaluated the delete replication
decision and queued a delete marker or a version purge for the targets.
That is the content of the still-open PR #240. It changes behavior for
every bucket whose replication rule replicates deletes or delete
markers, the mc default: a target with longer retention loses versions
on the source's schedule, and a purge keeps its space as a pending
tombstone until the target confirms. SILO, like S3, does not replicate
lifecycle deletes; an opt-in can come later. The release did not
replicate them.

Remove exactly the replication parts: the decision callbacks and the
post-delete scheduling in applyExpiryOnNonTransitionedObjects and
expireTransitionedObject, the scheduling in deleteObjectVersions, and
ilmPurgeToDelete; the scanner builds noncurrent entries as before. The
rest of #276 stays: the hot-tier delete before the remote one, the
free-version retry record, the lifecycle-change fence and the migration
completion checks. API deletes still replicate, and the replication heal
still handles persisted pending markers and purges. As in the release,
the replication heal also resyncs an empty-state marker when
existing-object replication applies to it.

The delete-all variant of the scheduling, which queued a task with an
empty decision, goes with it.

Tests: the scanner's noncurrent purge, run with replication configured,
deletes the version at once and queues nothing; an ILM marker carries
no replication state and the heal leaves it unless existing-object
replication applies, in which case it is resynced as before; an API
version delete still queues a purge. The cross-pool batch, dispatch and
decommission tests now assert no replication, and a decommission whose
expiry used to wait for the target completes in one run. Adding back the
scanner's decision makes the first two fail.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Feng Ruohang <rh@vonng.com>
This commit is contained in:
Feng Ruohang
2026-11-06 18:53:27 +08:00
parent d56b1063b9
commit 1bd0b1b04d
9 changed files with 236 additions and 427 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cmd/erasure-server-pool-lifecycle_test.go
+3 -1
View File
@@ -40,6 +40,8 @@ type splitILM struct {
*migrationILM
ids map[string]string // object and label -> version ID
bodies map[string]string // body -> label
// replication is the replication configuration the scanner runs with.
replication replicationConfig
}
func newSplitILM(t *testing.T, status versioning.State, rules string) *splitILM {
@@ -147,7 +149,7 @@ func (s *splitILM) scan(pool int) {
for i, fi := range fivs.Versions {
objInfos[i] = fi.ToObjectInfo(s.bucket, object, vc != nil && vc.Versioned(object))
}
item := scannerItem{bucket: s.bucket, objectName: object, lifeCycle: lc}
item := scannerItem{bucket: s.bucket, objectName: object, lifeCycle: lc, replication: s.replication}
item.applyActions(ctx, s.z, objInfos, lr, &sizeSummary{}, nil)
}
s.runQueue()