With only two instances, replication may be the way to go. Or send updates to both.
Solr Cloud is much more tightly coupled, requires Zookeeper, etc. There are more ways for two Solr Cloud nodes to fail, compared with two Solr nodes using old-style replication. In general, a loosely-coupled system will be more robust. You should look at Solr Cloud if you need sharding or near real time. wunder On Jul 15, 2013, at 5:54 AM, Jack Krupansky wrote: > * Go with SolrCloud - unless you think you're smarter than Yonik and Mark > Miller. > * "Replicas" are used for both query capacity and resilience (HA). > * "Shards" are used for increased index capacity (number of documents) and to > reduce query latency (parallel processing of portions of a query.) > * You need at least three zookeepers for HA. They need to be external to the > cluster in production. > * Load balancing - you need to do your own testing to confirm whether you > need it. If so, that is outside of Solr. > * SolrCloud automatically recovers nodes when they come back up. > > -- Jack Krupansky > > -----Original Message----- From: Mysurf Mail > Sent: Monday, July 15, 2013 8:32 AM > To: solr-user@lucene.apache.org > Subject: Running Solr in a cluster - high availability only > > Hi, > I would like to run two Solr instances on different computers as a cluster. > My main interest is High availability - meaning, in case one server crashes > or is down there will be always another one. > > (my performances on a single instance are great. I do not need to split the > data to two servers.) > > Questions: > 1. What is the best practice? > Is it different than clustering for index splitting? Do I need Shards? > 2. Do I need zoo keeper? > 3. Is it a container based configuration (different for jetty and tomcat) > 4, Do I need an external NLB for that ? > 5. When one computer is up after crashing. how dows it updates its index? -- Walter Underwood wun...@wunderwood.org
