Thanks to all,
i done by using multicore,
vishal parekh
--
View this message in context:
http://lucene.472066.n3.nabble.com/how-to-do-offline-adding-updating-index-tp2923035p3019219.html
Sent from the Solr - User mailing list archive at Nabble.com.
much of a pain as that can be. It seems there are lots of significant
variables.
From: kenf_nc [ken.fos...@realestate.com]
Sent: Tuesday, May 10, 2011 4:01 PM
To: solr-user@lucene.apache.org
Subject: Re: how to do offline adding/updating index
Master/slave
___
From: kenf_nc [ken.fos...@realestate.com]
Sent: Wednesday, May 11, 2011 9:46 AM
To: solr-user@lucene.apache.org
Subject: Re: how to do offline adding/updating index
My understanding is that the Master has done all the indexing, that
replication is a series of file copie
My understanding is that the Master has done all the indexing, that
replication is a series of file copies to a temp directory, then a move and
commit. The slave only gets hit with the effects of a commit, so whatever
warming queries are in place, and the caches get reset. Doing too many
commits to
Replication large files can be bad for OS page cache as files being written are
also written to the page cache. Search latency can grow due to I/O for getting
the current index version back into memory. Also, Solr cache warming can casue
a doubling of your heap usage.
Frequent replication in an
Thanks - that sounds like what I was hoping for. So the I/O during
replication will have *some* impact on search performance, but
presumably much less than reindexing and merging/optimizing?
-Mike
Master/slave replication does this out of the box, easily. Just set the slave
to update on Opti
Master/slave replication does this out of the box, easily. Just set the slave
to update on Optimize only. Then you can update the master as much as you
want. When you are ready to update the slave (the search instance), just
optimize the master. On the slave's next cycle check it will refresh itsel
I think the key question here is what's the best way to perform indexing
without affecting search performance, or without affecting it much. If
you have a batch of documents to index (say a daily batch that takes an
hour to index and merge), you'd like to do that on an offline system,
and then
Under the hood, Lucene can support this by keeping multiple commit
points in the index.
So you'd make a new commit whenever you finish indexing the updates
from each hour, and record that this is the last "searchable" commit.
Then you are free to commit while indexing the next hour's worth of
cha
One approach is to use Solr's replication features. Index to a 'master',
periodically replicate to 'slave' on which all the searching is done.
That's what I do; my master and slave are in fact on the same server (one with
a bunch of CPUs and RAM however), although not alternate cores in a mult
10 matches
Mail list logo
