https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
a
random
doesn't balance segments. Is there a reason you are using that strategy? If you are on the latest version of Druid, please use the strategy 
cost
with round robin segment assignment enabled in the coordinator dynamic configuration for fast loading + optimal balancing
j
thanks! But we use Druid0.17.1, we need to decommission many historical, it takes too long time to calculate where segment need to move. I see the round robin used in 25.0.0 or greater.
I see this pr, and find it not used for decommission nodes move segment process. It is used for loadRule assign segment. Is there any way to speed up the node move process of decommissioning in Druid 0.17.1? https://github.com/apache/druid/pull/13367
a
We generally operate with at least 2 replicas per segment and then restart one historical after another, ensuring that there are at least 2 replicas before each historical restart. So we rely on load operations rather than moves from decommissioning servers
Have you tried 
cachingCost
? If your segments in the server do not have mixed granularities and you also limit the max segments in node loading queue (100 may be a good value), this strategy is pretty fast. Please note that cachingCost is no longer recommended and is actually being deprecated. (but you could use it for faster decommissioning and see if it helps with your cluster's segments)
j
Yes, we try cachingCost. We have 2 replicas, if we want to offline some historical node. How to ensure the offline historical’s segment has load to other historical? Which metric you check? such as assign/segments?
a
You could check 
segment/underreplicated/count
(https://druid.apache.org/docs/0.17.1/operations/metrics.html#coordination) which should be zero before decommissioning a historical
Open in Slack
PreviousNext
Powered by