Alexander, sorry for the delay in replying. I wanted to test out a few
hunches that I had before I get back to you.
Hurray!!! I was able to resolve the issue. The problem was with the
cache settings in the solrconfig.xml. It was taking almost 15-20
minutes to warm up the caches on each commit, as
Ravi,
what is the replication configuration on both master and slave?
Also could you list of files in the index folder on master and slave
before and after the replication?
-Alexander
On Fri, 2011-05-13 at 18:34 -0400, Ravi Solr wrote:
Sorry guys spoke too soon I guess. The replication
Sorry guys spoke too soon I guess. The replication still remains very
slow even after upgrading to 3.1 and setting the compression off. Now
Iam totally clueless. I have tried everything that I know of to
increase the speed of replication but failed. if anybody faced the
same issue, can you please
Thank you Mr. Bell and Mr. Kanarsky, as per your advise we have moved
from 1.4.1 to 3.1 and have made several changes to configuration. The
configuration changes have worked nicely till now and the replication
is finishing within the interval and not backing up. The changes we
made are as follows
Mr. Bell,
Thank you for your help. Yes, the full index replicated every
1000, 1, 10 etc, if mergeFactor is 10 as per it's definition.
We do index every 5 minutes and replicate every 3 minutes just to make
sure consumers have immediate access to the indexed docs.
Thanks,
Ravi Kiran
Ravi,
if you have what looks like a full replication each time even if the
master generation is greater than slave, try to watch for the index on
both master and slave the same time to see what files are getting
replicated. You probably may need to adjust your merge factor, as Bill
mentioned.
Ravi,
as far as I remember, this is how the replication logic works (see
SnapPuller class, fetchLatestIndex method):
1. Does the Slave get the whole index every time during replication or
just the delta since the last replication happened ?
It look at the index version AND the index
Hello Mr. Kanarsky,
Thank you very much for the detailed explanation,
probably the best explanation I found regarding replication. Just to
be sure, I wanted to test solr 3.1 to see if it alleviates the
problems...I dont think it helped. The master index version and
generation are
OK let me rephrase.
In solrconfig.xml there is a setting called mergeFactor. The default is
usually 10.
Practically it means there are 10 segments. If you are doing fast delta
indexing (adding a couple documents, then committing),
You will cycle through all 10 segments pretty fast.
It appears
Hello Mr. Bell,
Thank you very much for patiently responding to my
questions. We optimize once in every 2 days. Can you kindly rephrase
your answer, I could not understand - if the amount of time if 10
segments, I believe that might also trigger a whole index, since you
cycled
I did not see answers... I am not an authority, but will tell you what I
think
Did you get some answers?
On 5/6/11 2:52 PM, Ravi Solr ravis...@gmail.com wrote:
Hello,
Pardon me if this has been already answered somewhere and I
apologize for a lengthy post. I was wondering if
Hello,
Pardon me if this has been already answered somewhere and I
apologize for a lengthy post. I was wondering if anybody could help me
understand Replication internals a bit more. We have a single
master-slave setup (solr 1.4.1) with the configurations as shown
below. Our environment is
12 matches
Mail list logo
