[
https://issues.apache.org/jira/browse/SOLR-16879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761075#comment-17761075
]
ASF subversion and git services commented on SOLR-16879:
--------------------------------------------------------
Commit 585ba9ba5f9afdaf00ff2071504c4b62f2234d1f in solr's branch
refs/heads/main from Pierre Salagnac
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=585ba9ba5f9 ]
SOLR-16879: throttle BACKUPCORE, RESTORECORE, SPLIT (#1864)
Core Admin operations that are submitted with "async" that are also considered
expensive will use a different thread pool of a lower size. Expensive tasks
are: BACKUPCORE, RESTORECORE, SPLIT
Co-authored-by: Pierre Salagnac <psalag...@salesforce.com>
Co-authored-by: David Smiley <dsmi...@salesforce.com>
> Throttle concurrent backups/restores per node
> ---------------------------------------------
>
> Key: SOLR-16879
> URL: https://issues.apache.org/jira/browse/SOLR-16879
> Project: Solr
> Issue Type: Improvement
> Components: Backup/Restore
> Affects Versions: 9.2.1
> Reporter: Pierre Salagnac
> Priority: Minor
> Time Spent: 3h
> Remaining Estimate: 0h
>
> If the collection is large enough, there very well could be many shards on
> one host and it could saturate the IO. Same issue if we backup many
> collections concurrently.
> We should have a protection mechanism, so a Solr node does not have transient
> failures during a large backup or restore.
--
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
