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>
