This message was deleted.

what's the replication factor? What I've seen is that if you have 2 segments (just 2) and 3 nodes, on druid 0.21, they keep load/unloading between the nodes until I add more segments

@Didip Kerabat do you have any tiering across 20 historical nodes?

The coordinator logs would give you more insights into why this is happening.

You could try switching from cachingCost to cost and see if it helps. (Needs coordinator restart) Cost is generally slower than cachingCost but the following changes to the dynamic config might help. If you are on 25.0.0, please try setting

useRoundRobinSegmentAssignment

to true as this will assign segments in a round robin fashion across servers and balance them later with the chosen strategy. You could then increase

maxSegmentsToMove

, and set

useBatchedSegmentSampler

to true for faster balancing.

the RF is 2, this cluster is on Druid 23. We don’t have any tiering between 20 historical servers. They are all the same. Thanks for informing me of

useRoundRobinSegmentAssignment

. I didn’t know that.

oh, I read it again, you have just 2 segments per date, now it makes more sense to me why you have 20 historicals I was thinking "why so many spare servers"

Follow up question, the partitioning strategy does not use historical hostname as part of its key right? Which means even though I only have 2 segments per partition date, they should still be spread out across 20 historical servers, right?

i'd try

cost

instead of

cachingCost

and see if that helps… I've noticed some discrepancies between them and

cost

generally seems to do a better job