On 1/19/2011 2:56 PM, Tri Nguyen wrote:
Yes, during a commit.
I'm planning to do as you suggested, having a master do the indexing and replicating the index to a slave which leads to my next questions.
During the slave replicates the index files from the master, how does it impact performance on the slave?
That I am not certain, because I haven't done it yet myself, but I am
optimistic it will be tolerable.
As with any commit, when the slave replicates it will temporarily make a
second copy of any changed index files (possibly the whole index), and
it will then set up new searchers on the new copy of the index, and it
will warm that new index, and then once warmed, it'll switch live
searches over to the new index, and delete any old copies of indexes.
So you may still need a bunch of 'extra' RAM in the JVM to accomodate
that overlap period. You will need some extra diskspace. But the actual
CPU.... I mean, it will take some CPU for the slave to run the new
warmers, but it should be tolerable not very noticeable... I'm hoping.
One main benefit of the replication setup is that you can _optimize_ on
the master, which will be completely out of the way of the slave.
Even with the replication setup, you still can't commit (ie pull down
changes from master) "near real time" in 1.4 though, you can't commit so
often that a new index is not done warming when a new commit comes in,
or your Solr will grind to a halt as it uses too much CPU and RAM. There
are various ways people have suggested you can try to work around this,
but I havne't been too happy with any of em, I think it's best just not
to commit/pull down changes from master that often. Unless you REALLY
need to, and are prepared to get into details of Solr to figure out how
to make it work as well as it can.
