Thank you Ram.
On Mon, Jan 26, 2015 at 1:49 AM, Ramkumar R. Aiyengar <
andyetitmo...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/SOLR-6359 has a patch which allows
> this to be configured, it has not gone in as yet.
>
> Note that the current design of the UpdateLog causes it to be l
https://issues.apache.org/jira/browse/SOLR-6359 has a patch which allows
this to be configured, it has not gone in as yet.
Note that the current design of the UpdateLog causes it to be less
efficient if the number is bumped up too much, but certainly worth
experimenting with.
On 22 Jan 2015 02:47,
Shalin:
Just to see if my understanding is correct, how often would you expect <2> to
occur? My assumption so far is that it would be quite rare that the leader
and all replicas happened to hit autocommit points at the same time and thus it
would be save to just bring down a few segments. But that
Thank you Shalin.So in a system where the indexing rate is more than 5K TPS
or so the replica will never be able to recover through peer sync
process.In my case I have mostly seen step 3 where a full copy happens
and if the index size is huge it takes a very long time for replicas to
recover.
Hi Nishanth,
The recovery happens as follows:
1. PeerSync is attempted first. If the number of new updates on leader is
less than 100 then the missing documents are fetched directly and indexed
locally. The tlog tells us the last 100 updates very quickly. Other uses of
the tlog are for durability
Hello Everyone,
I am hitting a few issues with solr replicas going into recovery and then
doing a full index copy.I am trying to understand the solr recovery
process.I have read a few blogs on this and saw that when leader notifies
a replica to recover(in my case it is due to connection resets)
