This message was deleted.

I've been trying to find it. I found this: https://druid.apache.org/docs/latest/design/coordinator.html#segment-availability Which seems to indicate there is a dropped segment lifetime before being reassigned to other historicals. But like you, I can't find a parameter with that behavior description. The nearest I found is:

druid.segmentCache.dropSegmentDelayMillis

which says

How long a process delays before completely dropping segment.

But this is a historical property, not sure if the coordinator would also pick it up or if it could be set to something larger. Seems more like a delay in deleting local files after the instruction to drop is received. I would expect it to be a coordinator configuration. I'll let you know if I find anything.

in general there is an assumption that if historicals go away then their data should be rebalanced starting immediately however, you can slow down that process via

replicationThrottleLimit

(see https://druid.apache.org/docs/latest/configuration/index.html#dynamic-configuration), assuming other replicas exist elsewhere. you might find this helpful also i wonder why your historical frequently crashes? if i was you i would try to fix that— it sounds annoying! maybe we can help with this issue too.