: No I didn't. I thought you aren't supposed to run optimize on slaves. Well
correct, you should make all changes to the master. : but it doesn;t matter now, as I think its fixed now. I just added a dummy : document on master, ran a commit call and then once that executed ran an : optimize call. This triggered snapshooter to replicate the index, which : somehow resulted in normal index size at slaves. My hunch: are you running on windows? Windows filesystems have issues with trying to delete a file while processes still have the file handle open. Since Solr needs those "old" filehandles to continue serving requests while it opens up the "new" copy of the index, those files wind up left on disk. the *next* time a new index is opened, it tries to delete those files again, and then they succeed... http://wiki.apache.org/lucene-java/LuceneFAQ#Why_do_I_have_a_deletable_file_.28and_old_segment_files_remain.29_after_running_optimize.3F ...if you notice this situation happen again, check and see if you have a "deletables" file. -Hoss
