SOLR-3033 is related to ReplcationHandler's ability to do backups. It allows you to specify how many backups you want to keep. You don't seem to have any backups configured here so it is not an applicable parameter (note that SOLR-3033 was committed to trunk recently but the config param was made "maxNumberOfBackups" ... see http://wiki.apache.org/solr/SolrReplication#Master )
I can only take a wild guess why you have the temporary increase in index size. Could it be that something is locking the old segment files so they do not get deleted on optimize? Then maybe they are subsequently getting cleaned up at your next commit and restart ? Finally, keep in mind that doing optimizes aren't generally recommended anymore. Everyone's situation is different, but if you have good settings for "mergeFactor" and "ramBufferSizeMB", then optimize is (probably) not going to do anything helpful. James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Ahmet Arslan [mailto:iori...@yahoo.com] Sent: Wednesday, March 14, 2012 4:25 PM To: solr-user@lucene.apache.org Subject: Re: index size with replication > Another note.. if I reload solr app > it goes back down in size. > > here is my replication settings on the master: > > <requestHandler name="/replication" > class="solr.ReplicationHandler" > > <lst name="master"> > <str > name="replicateAfter">startup</str> > <str > name="replicateAfter">commit</str> > <str > name="replicateAfter">optimize</str> > <int > name="numberToKeep">1</int> > <str > name="confFiles">schema.xml,stopwords.txt,elevate.xml</str> > <str > name="commitReserveDuration">00:00:30</str> > </lst> > </requestHandler> Could it be https://issues.apache.org/jira/browse/SOLR-3033 ?
