Hi Jason, Would that not mean if one of the master indexes went down then a subset of data would be offline?
Rob. -----Original Message----- From: jason rutherglen [mailto:[EMAIL PROTECTED] Sent: 24 March 2006 18:32 To: solr-user@lucene.apache.org Subject: Re: To cluster, or not to cluster... It should be possible to do clustering if you divide your master index over multiple master servers. Then write a wrapper around the SolrClient API using something like MultiSearcher. From what I know this would work, could be wrong. ----- Original Message ---- From: Clay Webster <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Friday, March 24, 2006 8:54:45 AM Subject: Re: To cluster, or not to cluster... On 3/24/06, Robert Haycock <[EMAIL PROTECTED]> wrote: > > Is it/will it be possible to cluster solr? > > We have a distributed system and it would be nice if we could replicate > the index to improve performance. > > Solr does not have replication. But it does have a very nice index distribution system. Solr can be run in a master/slave setup. The master receives all the changes. For each commit a snapshooter index can be made. The slaves can run the snappuller with whatever polling frequency they like. Each snapshot is then snapinstalled in the slave and can have its cache warmed (while serving queries from the older index). Slaves can come on line with new indexes out of sync. But if your slave hardware is the same and your pulling and shooting well-understood, and you make warming time-based it probably will not be a problem. This distribution is noted by each slave in the master. That's as tied together as they get (not much). So, if you have a requirement that they must all be in index-version-sync you could tie them closer and extend Solr. --cw
