To pile on to Chris' comment. In the M/S situation you describe, all the query traffic goes to the slave.
True, this relieves the slave from doing the work of indexing, but it _also_ prevents the master from answering queries. So going to SolrCloud trades off indexing on _both_ machines to also querying on _both_ machines. And this doesn't even take into account the issues involved in recovering if one or the other (especially the master) goes down, which is automatically handled in SolrCloud. Add to that the fact that memory management is _very_ significantly improved starting with Solr 4x (see: https://lucidworks.com/blog/2012/04/06/memory-comparisons-between-solr-3x-and-trunk/) and my claim is that you are _far_ better off using SolrCloud than M/S in 5x. As always, YMMV of course. Best, Erick On Thu, Nov 5, 2015 at 1:12 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : The database of server 2 is considered the "master" and it is replicated > : regularly to server 1, the "slave". > : > : The advantage is the responsiveness of server 1 is not impacted with server > : 2 gets busy with lots of indexing. > : > : QUESTION: When deploying a SOLR 5 setup, do I set things up the same way? > : Or do I cluster bother servers together into one "cloud"? That is, in > : SOLR 5, how do I ensure the indexing process will not impact the > : performance of the web app? > > There is nothing preventing you from using a master slave setup with Solr > 5... > > https://cwiki.apache.org/confluence/display/solr/Index+Replication > > ...however if you do so you have to take responsibility for the same > risks/tradeoffs that existed with this type of setup in Solr 3... > > 1) if the "query slave" goes down, you can't serve quiers w/o manually > redirecting traffic to your "indexing master" > > 2) if the "indexing master" goes down you can't accept index updates w/o > manually redirecting update to your "query slave" -- and manually > rectifying the descrepencies if/when your master comes back online. > > > When using a cloud based setup these types of problems go away because > there is no single "master", clients can send updates/queries to any node > (and if you use SolrJ your clients will be "ZK aware" and know > automatically if/when a node is down or new nodes are added) ... > many people concerned about performance/reliability consider these > benefits more important then the risks/tradeoffs of performance impacts of > indexing directy to nodes that are serving queries -- especially with > other NRT (Near Real Time) related improvements to Solr over the years > (Soft Commits, DocValues instead of FieldCache, etc...) > > > -Hoss > http://www.lucidworks.com/
