You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Webster Homer <we...@milliporesigma.com> on 2020/10/27 18:17:05 UTC

Solrcloud create collection ignores createNodeSet parameter

We have a solrcloud set up with 2 nodes, 1 zookeeper and running Solr 7.7.2 This cloud is used for development purposes. Collections are sharded across the 2 nodes.

Recently we noticed that one of the main collections we use had both replicas running on the same node. Normally we don't see collections created where the replicas run on the same node.

I tried to create a new version of the collection forcing it to use both nodes. However, that doesn't work both replicas are created on the same node:
/solr/admin/collections?action=CREATE&name=sial-catalog-product-20201027&collection.configName=sial-catalog-product-20200808&numShards=2&replicationFactor=1&maxShardsPerNode=1&createNodeSet=uc1a-ecomdev-msc02:8983_solr,uc1a-ecomdev-msc01:8983_solr
The call returns this:
{
    "responseHeader": {
        "status": 0,
        "QTime": 4659
    },
    "success": {
        "uc1a-ecomdev-msc01:8983_solr": {
            "responseHeader": {
                "status": 0,
                "QTime": 3900
            },
            "core": "sial-catalog-product-20201027_shard2_replica_n2"
        },
        "uc1a-ecomdev-msc01:8983_solr": {
            "responseHeader": {
                "status": 0,
                "QTime": 4012
            },
            "core": "sial-catalog-product-20201027_shard1_replica_n1"
        }
    }
}

Both replicas are created on the same node. Why is this happening?

How do we force the replicas be placed on different nodes?



This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

Re: Solrcloud create collection ignores createNodeSet parameter

Posted by Erick Erickson <er...@gmail.com>.
You’re confusing replicas and shards a bit. Solr tries its best to put multiple replicas _of the same shard_ on different nodes. You have two shards though with _one_ replica. Thi is a bit of a nit, but important to keep in mind when your replicatinFactor increases. So from an HA perspective, this isn’t catastrophic since both shards must be up to run.

That said, it does seem reasonable to use all the nodes in your case. If you omit the createNodeSet, what happens? I’m curious if that’s confusing things somehow. And can you totally guarantee that both nodes are accessible when the collection is created?

BTW, I’ve always disliked the parameter name “maxShardsPerNode”, shards isn’t what it’s actually about. But I suppose “maxReplicasOfAnyIndividualShardOnASingleNode” is a little verbose...

> On Oct 27, 2020, at 2:17 PM, Webster Homer <we...@milliporesigma.com> wrote:
> 
> We have a solrcloud set up with 2 nodes, 1 zookeeper and running Solr 7.7.2 This cloud is used for development purposes. Collections are sharded across the 2 nodes.
> 
> Recently we noticed that one of the main collections we use had both replicas running on the same node. Normally we don't see collections created where the replicas run on the same node.
> 
> I tried to create a new version of the collection forcing it to use both nodes. However, that doesn't work both replicas are created on the same node:
> /solr/admin/collections?action=CREATE&name=sial-catalog-product-20201027&collection.configName=sial-catalog-product-20200808&numShards=2&replicationFactor=1&maxShardsPerNode=1&createNodeSet=uc1a-ecomdev-msc02:8983_solr,uc1a-ecomdev-msc01:8983_solr
> The call returns this:
> {
>    "responseHeader": {
>        "status": 0,
>        "QTime": 4659
>    },
>    "success": {
>        "uc1a-ecomdev-msc01:8983_solr": {
>            "responseHeader": {
>                "status": 0,
>                "QTime": 3900
>            },
>            "core": "sial-catalog-product-20201027_shard2_replica_n2"
>        },
>        "uc1a-ecomdev-msc01:8983_solr": {
>            "responseHeader": {
>                "status": 0,
>                "QTime": 4012
>            },
>            "core": "sial-catalog-product-20201027_shard1_replica_n1"
>        }
>    }
> }
> 
> Both replicas are created on the same node. Why is this happening?
> 
> How do we force the replicas be placed on different nodes?
> 
> 
> 
> This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.
> 
> 
> 
> Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.