lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <ysee...@gmail.com>
Subject Re: ApacheCon EU slides
Date Tue, 11 Jul 2006 13:55:44 GMT
On 7/11/06, Tim Archambault <tarchambault@bangordailynews.net> wrote:
> Yonik,
>
> Thanks for the slides.
>
> Quick question. I'm looking at a new hosting provider for our newspaper
> website. When reviewing your "High Availability" slide, I see a lot of
> redundancy which is great, but it is not within my budget constraints (It's
> a limitation that causes me to not sleep well at night).  Could I create my
> Solr master here at my company (Internal network0 and have it communicate
> with my live Solr instance where our live website lives? Does this make any
> sense?

Only if there is a good deal of network bandwidth between the master
and the searchers, and you don't mind using it, or if you don't need
index changes to go "live" that frequently. Otherwise, it's probably
not the best idea.

You will need some "updater" piece of software somewhere that is
responsible for sending index changes to Solr.  Network-wize it might
also make sense to put the master close to the updater and database,
if you are reading from one.

> Physically what is the difference between "Solr Master" and "Solr Searcher".

Very little actually.  The hardware we happen to use is the same.
A master has a little config change to solrconfig.xml that takes a
snapshot when a commit is done.... that's it from the perspective of
Solr proper.  You can actually query masters, and you can send updates
to searchers, if you really want to.

To complete the master/searcher picture, there is other unix-level config done:
The master runs an rsync server, and the slave has a cron job set up
to periodically check the master for a new snapshot via ssh, and then
rsync the changes if so.

You don't really need a master though...
You can get by with two or more searchers, and your index updater can
send changes to all searchers.  One of the downsides of this approach
is that the searchers could get out of sync, and you would have to get
them back in sync manually.

> From the diagram I can't tell if the "Solr Searcher" represents a physical
> server or just a logical representation of a user session searching the Solr
> Master.

The searchers are physical servers, for scaling to increasing search
traffic, and for redundancy.

A master could be co located with one of the searchers though.
One could even make one of the searchers an actual master.   The
downside to that is that when you do a commit, the master will make
changes visible sooner than other searchers since it doesn't need to
rsync the changes.


-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

Mime
View raw message