> I thought about this situation and I must admit that it's a tricky one. > We should offer the option to configure the slaves to swit> > Yes, I do understand that SolrCloud is the future. > However, removing this singlePointOfFailure from the traditional > master-slave deployment model would not require a lot of effort IMHO and > would give huge benefit in term of choice. > > The other question is: How many sites are on SolrCloud? How many are still > on master-slave?
For my redundant Solr install, I don't use replication and I don't use SolrCloud. At one time, I had a master/slave replication setup running Solr 1.4.1. When 3.1.0 came out, I wanted to upgrade. The problem was that it's not possible to replicate between 1.4.1 and any later release, because the javabin format changed in 3.1.0 and does not offer any backwards compatibility. What we were forced to do is rewrite the index updating software so that it would update both copies of the distributed index in parallel. By the time I had this completed, 3.2.0 was out and that was what we upgraded to. This offers us capabilities that cannot be matched by a distributed/replicated SolrCloud. We are able to try out a different configuration and/or schema on one copy of our index, without affecting the index used by the production applications. We can upgrade or change any component on only one copy of the index. When such a change is made for testing purposes, we can independently rebuild either copy of the index from scratch, and through Solr's ping handler, can instantly switch the active copy of the index from the point of view of the load balancer. A dev version of the application can be pointed at the offline copy of the index. Because SolrCloud shares the configuration between all replicas, and master/slave replication copies the actual index, treating each copy of the index as an independent entity in these scenarios is not possible. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
