lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Lea <>
Subject Re: Lucene index architecture question
Date Wed, 25 Mar 2009 16:37:47 GMT
My vote would be for 2 indexes, one on each server.  We do this by
having a master update-only index which happens to be on one of the
search servers, but could be anywhere, and that is copied to read only
versions on the 2 search servers, via rsync.  When changes have been
installed the search daemons are told to reopen their local copy of
the index.

I don't think there are any classes to update multiple indexes and
lucene does locking to prevent multiple processes updating the same
index at the same time.

And as Danil says, you might want to take a look at solr which I think
takes care of all this for you.


On Wed, Mar 25, 2009 at 4:18 PM, kgeeva <> wrote:
> I have an application clustered on two servers. Is the best practice to have
> two lucene indexes - one on each server for the app or is it best to have
> one index (on one physical path) which can be shared by both servers?
> Both the indexes need to be in sync 24/7.
> I would need to do updates and searches on the indexes. If I have two
> indexes and an update is made on one server should I call a method to update
> the second server index also to keep it in sync?
> I have read of the classes MultiSearcher and ParalleMultiSearcher to use for
> searching multiple indexes.
> Are there similar classes to update multiple indexes?
> Are there any issues with having a shared path for the index and multiple
> servers updating the same index?
> Thank you,
> Koshy
> --
> View this message in context:
> Sent from the Lucene - Java Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message