No, this second part will not work. Lucene creates new index files
independent of when and what you index. So copying files from one
indexer to another will never work: the indexes will be out of sync.
You don't have to change your UI to use distributed search. You can
add a new <requestHandler> that fowards requests to the other shards
(with different URLs!).
<requestHandler name="broker" class="solr.SearchHandler" >
<lst name="invariants">
<str name="shards">shard1,shard2</str>
</lst>
</requestHandler>
Now, solr/broker?q=word goes to shard1/solr?q=word and
shard2/solr?q=word with no UI changes.
I usually make a new core to broker these sharded queries. It makes it
easier to track what I'm doing.
On Thu, Jul 8, 2010 at 7:22 PM, bbarani <bbar...@gmail.com> wrote:
>
> Hi,
>
> Thanks a lot for your reply.
>
> As you suggested the best option is to have another core started up at same
> / different port and use shards for distributed search.
>
> I had also thought of another approach where I would be writing the real
> time data to both master and slave hence it will be available at slave when
> user is searching, also it would be present after replication of master to
> slave.
>
> Do you think my suggestion would work? I would surely go for shards but for
> time being I am planning to implement the 2nd approach as we need to make
> changes to the UI code if we are going for shards.
>
> Thanks,
> BB
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Realtime-Batch-indexing-tp952293p953410.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
--
Lance Norskog
goks...@gmail.com
