[
https://issues.apache.org/jira/browse/SOLR-16816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732594#comment-17732594
]
Houston Putman commented on SOLR-16816:
---------------------------------------
This issue is fixed in a different manor by SOLR-16806. The commit made for
this issue will be reverted, but the new tests and testing changes will be
included in SOLR-16806's commit.
I left the changelog entry for this issue, to highlight the importance of this
specific fix, as a part of SOLR-16806.
> AffinityPlacementPlugin should utilize the size of new replicas when making
> placements
> --------------------------------------------------------------------------------------
>
> Key: SOLR-16816
> URL: https://issues.apache.org/jira/browse/SOLR-16816
> Project: Solr
> Issue Type: Sub-task
> Components: AutoScaling
> Affects Versions: 9.0
> Reporter: Houston Putman
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The AffinityPlacementPlugin has logic to make sure that nodes are not loaded
> up with more indexes than they can handle. It does this by filtering out
> nodes in the selection process that have less free disk space than the
> minimalFreeDiskGB configured.
> However it doesn't take into account the size of the replicas it will create
> when doing this. So if the minimalFreeDiskGB is 30 GB, and the free disk
> space on a node is 50G, and a new replica's shard's leader uses 40GB for its
> index, then the plugin will happily choose this node, even though its likely
> that the node's free disk space will be 10GB after the replica is created,
> which is much smaller than the configured minimalFreeDiskGB.
> This information should also be used when sorting on prioritizedFreeDiskGB.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
