[ 
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512443#comment-16512443
 ] 

Varun Thacker commented on SOLR-11823:
--------------------------------------

There are multiple issues in play here
 # When you create a collection with replicationFactor = 3, the state.json will 
write out nrtReplicas=1 and replicationFactor=3 . They should be in sync. I 
will firstly fix that on SOLR-11676
 # When restoring a collection the restore parameter is not respected. I filed 
SOLR-12489 for that which needs to be fixed 

Let me fix these two underlying issues first shortly and then see how the 
maxShardsPerNode calculation is broken and how to fix it

> Incorrect number of replica calculation when using Restore Collection API
> -------------------------------------------------------------------------
>
>                 Key: SOLR-11823
>                 URL: https://issues.apache.org/jira/browse/SOLR-11823
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Backup/Restore
>    Affects Versions: 7.1
>            Reporter: Ansgar Wiechers
>            Priority: Major
>             Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a 
> 3-node cluster and tried using the backup/restore API for the first time. 
> Backup worked fine, but when trying to restore the backed-up collection I ran 
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo" 
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6 
> replicas per shard:
> {noformat}
> # curl -s -k 
> 'https://localhost:8983/solr/admin/collections?action=restore&name=demo&location=/srv/backup/solr/solr-dev&collection=demo&maxShardsPerNode=2&replicationFactor=2'
> {
>   "error": {
>     "code": 400,
>     "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number 
> ofavailable nodes.",
>     "metadata": [
>       "error-class",
>       "org.apache.solr.common.SolrException",
>       "root-error-class",
>       "org.apache.solr.common.SolrException"
>     ]
>   },
>   "exception": {
>     "rspCode": 400,
>     "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of 
> available nodes."
>   },
>   "Operation restore caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Solr cloud with available number of nodes:3 is insufficient for restoring a 
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2. 
> Consider increasing maxShardsPerNode value OR number of available nodes.",
>   "responseHeader": {
>     "QTime": 28,
>     "status": 400
>   }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well, 
> so it looks to me like the restore API multiplies the replication factor with 
> the number of nodes, which is not how the replication factor behaves in other 
> contexts. The 
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html] 
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>    The number of replicas to be created for each shard.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to