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 what 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
