[
https://issues.apache.org/jira/browse/KUDU-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079522#comment-18079522
]
Gabriella Lotz edited comment on KUDU-3732 at 6/1/26 2:22 PM:
--------------------------------------------------------------
Tracking in:
[https://gerrit.cloudera.org/c/24285/.|https://gerrit.cloudera.org/c/24285/]
Checking the flakiness of the new tests with the change:
[http://dist-test.cloudera.org/job?job_id=root.1780319168.20304]
1000/1000 pass
was (Author: JIRAUSER306153):
Tracking in:
[https://gerrit.cloudera.org/c/24285/.|https://gerrit.cloudera.org/c/24285/]
Investigated reading consensus state from the master's in-memory catalog in
CheckMoveCompleted() instead of issuing a GetConsensusState RPC on each polling
cycle.
The in-memory catalog is updated asynchronously via tablet reports. After
BulkChangeConfig is sent to schedule a replica move, there is a window, during
which the destination peer is not yet visible in the catalog.
CheckMoveCompleted cannot distinguish this from the peer having been genuinely
evicted by Raft: both cases appear identical in a catalog snapshot. The two
error conditions in the function ("destination disappeared", "replace attribute
not set") would therefore fire spuriously on every check until the catalog
catches up, causing moves to be cancelled, replace markers to be cleared, and
moves_per_tserver_ counters to leak.
The GetConsensusState RPC provides a causally consistent snapshot directly from
the Raft leader and is the correct data source for this function. The TODO is
removed and replaced with an explanatory comment. No functional change.
> Get consensus state from CatalogManager
> ---------------------------------------
>
> Key: KUDU-3732
> URL: https://issues.apache.org/jira/browse/KUDU-3732
> Project: Kudu
> Issue Type: Sub-task
> Reporter: Gabriella Lotz
> Assignee: Gabriella Lotz
> Priority: Major
>
> h2. Address the two existing TODOs
> Both are in
> {{{}[src/kudu/master/auto_rebalancer.cc](src/kudu/master/auto_rebalancer.cc){}}}:
> {*}TODO 1 (line 478){*}: {{remove moves that fail to be scheduled from
> 'replica_moves'}}
> Currently {{ExecuteMoves()}} iterates all moves but does not remove
> failed-to-schedule moves. Failed moves stay in the in-progress set, blocking
> future rounds from reconsidering those tablets. Fix: collect scheduling
> failures and erase them from {{replica_moves}} before returning, so
> {{CheckReplicaMovesCompleted}} only waits on actually-submitted moves.
> {*}TODO 2 (line 853){*}: {{Retrieve consensus state from CatalogManager
> instead}}
> {{CheckMoveCompleted()}} currently mirrors the tool-side
> {{CheckCompleteMove()}} — it issues RPCs. The better path reads consensus
> state from the master's in-memory catalog (already available via
> {{{}CatalogManager{}}}), eliminating the extra RPC round-trip per move. The
> implementation pattern exists in {{{}CatalogManager::GetTabletLocations{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
