We are seeing something very similar. Ours is intermittent and usually happens a great deal on random days. Often it seems to occur during large index updates on the master.
On 1/22/09 8:58 AM, "Shalin Shekhar Mangar" <shalinman...@gmail.com> wrote: > On Thu, Jan 22, 2009 at 10:18 PM, Jaco <jdevr...@gmail.com> wrote: > >> Hm, I don't know what to do anymore. I tried this: >> - Run Tomcat service as local administrator to overcome any permissioning >> issues >> - Installed latest nightly build (I noticed that item I mentioned before ( >> http://markmail.org/message/yq2ram4f3jblermd) had been committed which is >> good >> - Build a small master and slave core to try it all out >> - With each replication, the number of files on slave grows, and the >> directories index.xxxxxxx.. are not removed >> - I tried sending explicit commit commands to the slave, assuming it >> wouldn't help, which was true. >> - I don't see any reference to SolrDeletion in the log of the slave (it's >> there in the log of the master) >> >> Can anybody recommend some action to be taken? I'm building up some quite >> large production cores right now, and don't want the slaves to eat up all >> hard disk space of course.. > > > How frequently do you optimize your index? Does the number of files decrease > after an optimize? > > Can you execute the "indexversion" command: > /replication?command=indexversion > and then issue the following command with the returned index version: > /replication?command=filelist&indexversion=<INDEX_VERSION_BY_FIRST_COMMAND> > The above will give the list of files being used by that commit point. > > Can you compare the list of files given by the above command and with the > files you see in the solr/data/index directory? How many are extra?
