mirror of
https://github.com/milvus-io/milvus.git
synced 2026-07-20 09:45:43 +00:00
d0bdeb5e42
## What Add `dataCoord.import.l0ImportDisabled` (default **true**) and reject `ImportV2` requests carrying `l0_import=true` when it is set. - `pkg/util/paramtable/component_param.go`: new `L0ImportDisabled` param (default true). - `internal/datacoord/services.go`: in `ImportV2`, reject `l0_import` requests when disabled (fail-closed, before resource allocation). - `configs/milvus.yaml`: documented config entry. ## Why Importing L0 (delete-only) segments as separate L0 segments during a binlog/backup import is incompatible with `commit_timestamp` (two-phase-commit / replication imports). L0 deletes carry original timestamps while data segments are stamped with `commit_ts`, so `delete_ts < insert_ts` and the deletes are **silently dropped** — rows that should be deleted survive. Because this is silent data corruption, a fail-closed default is safer than relying on callers/operators to avoid it. See #51247. The intended replacement is to fold a backup's L0 deletes into per-segment deltalogs beforehand (offline L0 compaction), after which a plain restore drops the rows via the existing per-segment delta path. Operators who still need the legacy behavior can set the config to `false`. ## Rollout note This changes the default so that L0 import is rejected. Deployments relying on legacy L0 import must either (a) migrate their backups to the deltalog-folded form first, or (b) set `dataCoord.import.l0ImportDisabled=false`. The default flip is intended to be coordinated with the availability of the offline-compaction (wash) tooling. ## Testing - `paramtable` builds and its unit tests pass locally (pure-Go module). - Added `TestImportV2_L0ImportDisabledReturnsError` (rejects `l0_import` when disabled). The datacoord package requires the C++ core to build; local core is stale in this dev env, so the datacoord test is left to CI. issue: #51247 --------- Signed-off-by: bigsheeper <yihao.dai@zilliz.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>