arshilkxwork commented on code in PR #3356:
URL: https://github.com/apache/hugegraph/pull/3356#discussion_r4340777109
##########
hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/TaskScheduleService.java:
##########
@@ -582,6 +630,258 @@ public synchronized Map<Integer, Long>
balancePartitionLeader(boolean immediatel
return results;
}
+ /**
+ * The periodic entry of leader balancing. Calls balancePartitionLeader
only when the leader
+ * count per store has drifted further apart than
pd.balance-leader-max-skew and does not
+ * already match the planner's targets, so a balanced cluster sees no
transfers. Skipped while
+ * a shard group is not Normal, has no recent partition heartbeat or has a
shard that is
+ * neither Leader nor Follower, or while a store that holds a shard is not
active, because the
+ * target distribution would include a replica that cannot take a leader.
The plan uses the
+ * groups checked here; a group keeps its leader when this PD is no longer
the leader, the
+ * group changed, the target or leader store has not reported for
+ * BALANCE_LEADER_REPORT_MAX_AGE, or the target trails the leader by the
time the transfer
+ * would be sent.
+ *
+ * @return shard group id -> the store id its leader was moved to; empty
when skipped
+ */
+ public synchronized Map<Integer, Long> autoBalancePartitionLeader() throws
PDException {
+ // init() does not schedule this with a negative skew, which would
balance every run
+ int maxSkew = pdConfig.getBalanceLeaderMaxSkew();
+ if (!isLeader() || maxSkew < 0) {
+ lastLeaderIndexReports.clear();
+ earlierLeaderIndexReports.clear();
+ return new HashMap<>();
+ }
+
+ List<Metapb.ShardGroup> shardGroups = storeService.getShardGroups();
+ if (shardGroups.isEmpty()) {
+ return new HashMap<>();
+ }
+
+ List<Metapb.Store> stores = storeService.getActiveStores();
Review Comment:
Fixed in 2818f21a0. Each periodic run now reads the persisted Store states
(`StoreNodeService.getStores()`, not the TTL-backed active list) and only a
Store whose state is `Up` can be a target. Right before each transfer,
`canTakeLeader` reads the target's persisted state again and keeps the leader
where it is unless it is still `Up`. A Store PD has set to `Exiting` is
excluded even while its active entry lives on and `reallocShards` has added it
back as a Follower. A deferred transfer keeps its slot in the plan, as with the
other per-transfer checks, so the other groups are still balanced.
Tests:
- `testAutoBalancePartitionLeaderWithExitingStore`: all six leaders on store
1, store 3 still active but persisted as `Exiting`, then as `Offline`. Store 3
gets no leader and store 2 takes two.
- `testAutoBalancePartitionLeaderWithStoreExitingAfterRead`: store 3 is `Up`
when the run reads the Store list and turns `Exiting` before the transfers are
sent. The recheck keeps its two leaders on store 1.
Both fail without the change, with four transfers including two to store 3.
PD core suite: 211 tests, 0 failures, 2 skipped. `configuration.md` lists the
new condition.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
