Many thanks for your response. I worked with Solr until early version 4.0, then switched to ElasticSearch for a variety of reasons. I've used replication in the past with SolR, but with Elasticsearch basically I had no problem because it works similar to SolrCloud by default and with almost zero configuration.
Now I've a customer that want to use Solr, and he want the simplest possible stuff to maintain in production. Since most of the work will be done by Data Import Handler, having multiple parallel and independent machines is easy to maintain. If one machine fails, it is enough to configure another machine, configure core and restart DIH. I'd like to know if other people went through this path in the past. -- Gian Maria Ricci Cell: +39 320 0136949 -----Original Message----- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: giovedì 3 dicembre 2015 10:15 To: solr-user@lucene.apache.org Subject: Re: Use multiple istance simultaneously On 12/3/2015 1:25 AM, Gian Maria Ricci - aka Alkampfer wrote: > In such a scenario could it be feasible to simply configure 2 or 3 > identical instance of Solr and configure the application that transfer > data to solr to all the instances simultaneously (the approach will be > a DIH incremental for some core and an external application that push > data continuously for other cores)? Which could be the drawback of > using this approach? When I first set up Solr, I used replication. Then version 3.1.0 was released, including a non-backward-compatible upgrade to javabin, and it was not possible to replicate between 1.x and 3.x. This incompatibility meant that it would not be possible to do a gradual upgrade to 3.x, where the slaves are upgraded first and then the master. To get around the problem, I basically did exactly wh at you've described. I turned off replication and configured a second copy of my build program to update what used to be slave servers. Later, when I moved to a SolrJ program for index maintenance, I made one copy of the maintenance program capable of updating multiple copies of the index in parallel. I have stuck with this architecture through 4.x and moving into 5.x, even though I could go back to replication or switch to SolrCloud. Having completely independent indexes allows a great deal of flexibility with upgrades and testing new configurations, flexibility that isn't available with SolrCloud or master-slave replication. Thanks, Shawn
