Yes, ADDREPLICA is mostly equivalent, it's also supported going forward....
LegacyCloud should work temporarily, I'd change it going forward though. Finally, you'll want to add a "node" parameter to insure your replica is placed on the exact node you want, see the livenodes znode for the format... On Dec 19, 2017 16:06, "Greg Roodt" <gro...@gmail.com> wrote: > 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 > /solr/admin/collections?action=ADDREPLICA&collection=blah&shard=*shard1* > ``` > That seems mostly equivalent to writing that core.properties file that I am > using in 6.2 > > > > > > On 20 December 2017 at 09:34, Shawn Heisey <apa...@elyograg.org> 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 start.sh script > > > 3. This script creates a core.properties 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 core.properties, 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/solr.in.sh > > * 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 > > > > >
