lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Roodt <>
Subject Re: Solr 7.1 Solrcloud dynamic/automatic replicas
Date Wed, 20 Dec 2017 00:06:42 GMT
Thanks for the reply. So it sounds like the method that I'm using to
automatically add replicas on Solr 6.2 is not recommended and not going to
be supported in future versions.

A couple of follow up questions then:
* Do you know if running with legacyCloud=true will make this behaviour
work "for now" until I can find a better way of doing this?
* Will it be enough for my newly added nodes to then startup solr (with
correct ZK_HOST) and call the ADDREPLICA API as follows?
curl http://localhost:port
That seems mostly equivalent to writing that file that I am
using in 6.2

On 20 December 2017 at 09:34, Shawn Heisey <> wrote:

> On 12/19/2017 3:06 PM, Greg Roodt wrote:
> > Thanks for your reply Erick.
> >
> > This is what I'm doing at the moment with Solr 6.2 (I was mistaken,
> before
> > I said 6.1).
> >
> > 1. A new instance comes online
> > 2. Systemd starts solr with a custom script
> > 3. This script creates a file that looks like this:
> > ```
> > name=blah
> > shard=shard1
> > ```
> > 4. Script starts solr via the jar.
> > ```
> > java -DzkHost=....... -jar start.jar
> > ```
> The way that we would expect this to be normally done is a little
> different.  Adding a node to the cloud normally will NOT copy any
> indexes.  You have basically tricked SolrCloud into adding the replica
> automatically by creating a core before Solr starts.  SolrCloud
> incorporates the new core into the cluster according to the info that
> you have put in, notices that it has no index, and
> replicates it from the existing leader.
> Normally, what we would expect for adding a new node is this:
>  * Run the service installer script on the new machine
>  * Add a ZK_HOST variable to /etc/default/
>  * Use "service solr restart"to get Solr to join the cloud
>  * Call the ADDREPLICA action on the Collections API
> The reason that your method works is that currently, the "truth" about
> the cluster is a mixture of what's in ZooKeeper and what's actually
> present on each Solr instance.
> There is an effort to change this so that ZooKeeper is the sole source
> of truth, and if a core is found that the ZK database doesn't know
> about, it won't be started, because it's not a known part of the
> cluster.  If this goal is realized in a future version of Solr, then the
> method you're currently using is not going to work like it does at the
> moment.  I do not know how much of this has been done, but I know that
> there have been people working on it.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message