Hi Joel,
You're sort of describing the classic replication scenario, which you can
get started on by reading this: http://wiki.apache.org/solr/SolrReplication
Although I believe this is handled in the reference guide, too.
Generally speaking, the sorts of issues you mention are general issues
On Fri, Aug 1, 2014 at 10:48 AM, Joel Cohen jco...@grubhub.com wrote:
The only thing so far that I see as a hurdle here is the data set size vs.
heap size. If the index grows too large, then we have to increase the heap
size, which could lead to longer GC times. Servers could pop in and out of
Thanks for the input. For how long will the 'old style' of replication be
supported? Is it set to go away in Solr 5? I don't want to be stuck on
using an old version because we designed our application the wrong way.
On Mon, Aug 4, 2014 at 10:22 AM, Michael Della Bitta
It will always be supported under the current architecture as
SolrCloud uses master/slave style replication to bring replicas back
in-sync with leaders if a replica is too far out of date (currently,
too far 100 missed updates). So if it fits your architecture better,
then use it!
On Mon, Aug 4,
Hi,
We're in the development phase of a new application and the current dev
team mindset leans towards running Solr (4.9) in AWS without Zookeeper. The
theory is that we can add nodes quickly to our load balancer
programmatically and get a dump of the indexes from another node and copy
them over
