Rebase and retry the IdealState update in place on a version conflict during tier-relocation rebalance#19069
Open
Jackie-Jiang wants to merge 1 commit into
Open
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #19069 +/- ##
============================================
- Coverage 65.43% 65.42% -0.01%
Complexity 1421 1421
============================================
Files 3425 3425
Lines 216173 216219 +46
Branches 34239 34249 +10
============================================
+ Hits 141449 141458 +9
- Misses 63340 63376 +36
- Partials 11384 11385 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…ier-relocation rebalance When TableRebalancer moves segments in batches, each batch is applied with a version-checked IdealState update. On a continuously-ingesting strict realtime table (upsert/dedup), consuming-segment commits bump the IdealState version between the read and the write, so the update loses the compare-and-set. Previously every lost compare-and-set fell back to the top of the convergence loop, paying another ExternalView-convergence wait and target recompute, so the rebalance could make very little progress while ingestion continued. When the rebalance moves only tier segments (so the base placements of the partitions are unchanged), a concurrent write that does not touch the segments this batch moves cannot invalidate the batch. In that case, on a version conflict, re-read the IdealState, and if the concurrent change is disjoint from the segments this batch moves, rebase the batch onto the latest IdealState and retry the compare-and-set in place, without waiting for the ExternalView to converge again or recomputing the target. The retry is bounded; on overlap, re-read failure, or exhausting the retries, it falls back to the convergence loop as before. This builds on the target-recompute skip for tier-relocation rebalances: it reuses the same "moves only tier segments" condition to decide when a batch is safe to rebase, and refreshes the target from the adopted IdealState so the convergence check stays well-defined when a rebase pulls in concurrently added or removed segments.
Jackie-Jiang
force-pushed
the
rebalance-rebase-on-version-conflict
branch
from
July 23, 2026 23:35
ddcba5e to
931f4af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #19054. That PR reduces the cost of the version-checked
IdealStateupdate losing the compare-and-set during a tier-relocation rebalance of a strict realtime table (upsert/dedup); this PR reduces the cost of recovering from a lost compare-and-set.Each batch of segment moves is applied with a version-checked
IdealStateupdate. On a continuously-ingesting table, consuming-segment commits bump theIdealStateversion between the read and the write, so the update loses the compare-and-set. Previously every lost compare-and-set fell back to the top of the convergence loop — another ExternalView-convergence wait (~hundreds of ms) plus a target recompute — so the rebalance could make very little progress while ingestion continued.Change
When the rebalance moves only tier segments (the base placements of the partitions are unchanged — the same condition #19054 uses to skip the target recompute), a concurrent write that does not touch the segments this batch moves cannot invalidate the batch. So on a
ZkBadVersionException:IdealState.IdealState(reapply the batch's moves, preserving the concurrent changes) and retry the compare-and-set in place — no ExternalView wait, norebalanceTable.MAX_IDEAL_STATE_UPDATE_REBASE_ATTEMPTS), fall back to the convergence loop as before.On a successful rebase, the target assignment is refreshed from the adopted
IdealStateso thecurrentAssignment.equals(targetAssignment)convergence check stays well-defined when a rebase pulls in concurrently added (e.g. new consuming) or removed (e.g. retention) segments.Net effect: disjoint version churn is absorbed in place, so a tier relocation makes progress against a steady stream of consuming-segment commits instead of repeatedly restarting.
Notes
onRollbackis skipped since the batch did land) is the subtlest part and the best target for a unit test that injects a version bump between the read and the compare-and-set.