Simply use what the default was in the example solrconfig.xml... there is no need to modify that unless you are doing something advanced. In the config below, you show maxOptimizedCommitsToKeep=1, which will increase index size by always keeping around one optimized commit point.
-Yonik Apache Lucene Eurocon 2010 18-21 May 2010 | Prague On Fri, Apr 30, 2010 at 11:40 AM, Paleo Tek <paleo...@gmail.com> wrote: > Hi folks, > > In moving to 1.4, it was unclear to me how deletionPolicy was supposed to > work. I commit/optimize on a build server, then replicate to multiple > search servers. I don't need anything fancy for a deletion policy: save > one copy, and replicate on copy. But when I used no policy, sometimes the > index would be twice the normal size. In an effort to eliminate that, I put > in the explicit deletion below. But it STILL sometimes creates an index of > double the size. This is causing space problems on some on my replicated > servers. > > Can someone please explain what configuration I should apply to not ever > save any extra commits or optimized commits, so that my index and all > replicated copies of it will have a size of 1 index, rather than 2 indexes? > A summary of the theory behind that would be most welcome too. Thanks! > > -Jim > > > The deletion policy stanza from mainIndex in solrconfig.xml: > > > <deletionPolicy class="solr.SolrDeletionPolicy"> > <!-- The number of commit points to be kept --> > <str name="maxCommitsToKeep">0</str> > <!-- The number of optimized commit points to be kept --> > <str name="maxOptimizedCommitsToKeep">1</str> > <!-- > Delete all commit points once they have reached the given age. > Supports DateMathParser syntax e.g. > <str name="maxCommitAge">30MINUTES</str> > <str name="maxCommitAge">1DAY</str> > --> > </deletionPolicy> > > > >
