Re: Very long running replication.

[Jay Hill <ja...@gmail.com>]

Bumping this.

I'm seeing the error mentioned earlier in the thread - "Unable to download
<segment filename> completely. Downloaded 0!=<size>" often in my logs. I'm
dealing with a situation where maxDoc count is growing at a faster rate
than numDocs and is now almost twice as large. I'm not optimizing but
rather relying on the normal merge process to initiate the purging of
deleted docs. No purging has happened for months now and it snuck up on me.

Slaves are getting the newly indexed docs, but docs marked for delete are
never getting purged.

Index size is 23GB
Indexing about 3K docs an hour
Replication poll time is 60 seconds
Running Solr 3.6 (I know, we should upgrade...working on that)
autocommit every 30 seconds or 5K docs (so usually hitting the 30 second
threshold rather than the doc count)

Any pointers greatly appreciated!


On Fri, Jan 3, 2014 at 7:14 AM, anand chandak <an...@oracle.com>wrote:

> Folks, would really appreciate if somebody can help/throw some light on
> below issue . This issue is blocking our upgrade, we are doing a 3.x to 4.x
> upgrade and indexing around 100g of data.
>
> Any help would be highly appreciated.
>
> Thanks,
>
> Anand
>
>
>
> On 1/3/2014 11:46 AM, anand chandak wrote:
>
>> Thanks Shalin.
>>
>>
>> I am facing one issue while replicating, as my replication (very large
>> index 100g)is happening, I am also doing the indexing and I believe the
>> segment_N file is changing because of new commits. So would the replication
>> fail if the the filename is different from what it found when fetching the
>> filename list.
>>
>>
>> Basically, I am seeing this exception :
>>
>>
>> [explicit-fetchindex-cmd] ERROR org.apache.solr.handler.ReplicationHandler-
>> SnapPull failed :org.apache.solr.common.SolrException: Unable to
>> download _av3.fdt completely    . Downloaded 0!=497037
>>   2     at org.apache.solr.handler.SnapPuller$
>> DirectoryFileFetcher.cleanup(SnapPuller.java:1268)
>>   3     at org.apache.solr.handler.SnapPuller$DirectoryFileFetcher.
>> fetchFile(SnapPuller.java:1148)
>>   4     at org.apache.solr.handler.SnapPuller.downloadIndexFiles(
>> SnapPuller.java:743)
>>   5     at org.apache.solr.handler.SnapPuller.fetchLatestIndex(
>> SnapPuller.java:407)
>>   6     at org.apache.solr.handler.ReplicationHandler.doFetch(
>> ReplicationHandler.java:319)
>>   7     at org.apache.solr.handler.ReplicationHandler$1.run(
>> ReplicationHandler.java:220)
>>
>>
>> And I am trying to find the root cause of this issue. Any help ?
>>
>> Thanks,
>>
>> Anand
>>
>>
>> On 1/2/2014 5:32 PM, Shalin Shekhar Mangar wrote:
>>
>>> Replications won't run concurrently. They are scheduled at a fixed
>>> rate and if a particular pull takes longer than the time period then
>>> subsequent executions are delayed until the running one finishes.
>>>
>>> On Tue, Dec 31, 2013 at 4:46 PM, anand chandak <an...@oracle.com>
>>> wrote:
>>>
>>>> Quick question about solr replication : What happens if there's a
>>>> replication running for very large index that runs more than the
>>>> interval
>>>> for 2 replication ? would the automatic runs of replication interfere
>>>> with
>>>> the current running one or it would not even spawn next iteration of
>>>> replication ? Can somebody throw some light ?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>