: 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/
