;>> 5000
>>>> 10000
>>>>
>>>>
>>>>
>>>>
>>>> We will be updating to 3.6 fairly soon however. To be honest, from
>>>> what I've read, the Solr cloud is what we really want in the fut
pdating to 3.6 fairly soon however. To be honest, from
>>> what I've read, the Solr cloud is what we really want in the future
>>> but we will have to be patient for that.
>>>
>>> thanks in advance
>>>
>>> mvg,
>>> Jasper
>>>
t;>> You may also want to look at your Index report in SPM
>>> (http://sematext.com/spm) before/during/after replication and share what
>>> you see.
>>>
>>> Otis
>>>
>>> Performance Monitoring for Solr / ElasticSearch / HBase -
>
>> Otis
>> ----
>> Performance Monitoring for Solr / ElasticSearch / HBase -
>> http://sematext.com/spm
>>
>>
>>
>> - Original Message -
>>> From: Jasper Floor
>>> To: solr-user@lucene.apache.org
>>> Cc:
>>&g
>
> - Original Message -
>> From: Jasper Floor
>> To: solr-user@lucene.apache.org
>> Cc:
>> Sent: Thursday, May 10, 2012 9:08 AM
>> Subject: slave index not cleaned
>>
>> Perhaps I am missing the obvious but our slaves tend to run out of
&g
sday, May 10, 2012 9:08 AM
> Subject: slave index not cleaned
>
> Perhaps I am missing the obvious but our slaves tend to run out of
> disk space. The index sizes grow to multiple times the size of the
> master. So I just toss all the data and trigger a replication.
> However,
Perhaps I am missing the obvious but our slaves tend to run out of
disk space. The index sizes grow to multiple times the size of the
master. So I just toss all the data and trigger a replication.
However, can't solr handle this for me?
I'm sorry if I've missed a simple setting which does this for
