I've seen this happen when the configuration files change on the master and replication deems it necessary to do a core-reload on the slave. In this case, replication copies the entire index to the new directory then does a core re-load to make the new config files and new index directory go live. Because it is keeping the old searcher running while the new searcher is being started, both index copies to exist until the swap is complete. I remember having the same concern about re-starts, but I believe I tested this and solr will look at the "replication.properties" file on startup and determine the correct index dir to use from that. So (If my memory is correct) you can safely delete "index" so long as "replication.properties" points to the other directory.
I wasn't familiar with SOLR-1781. Maybe replication is supposed to clean up the extra directories and doesn't sometimes? In any case, I've found whenever it happens its ok to go out and delete the one(s) not being used, even if that means deleting "index". James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Artem Lokotosh [mailto:arco...@gmail.com] Sent: Wednesday, January 18, 2012 12:24 PM To: solr-user@lucene.apache.org Subject: Re: replication, disk space Which OS do you using? Maybe related to this Solr bug https://issues.apache.org/jira/browse/SOLR-1781 On Wed, Jan 18, 2012 at 6:32 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > So Solr 1.4. I have a solr master/slave, where it actually doesn't poll for > replication, it only replicates irregularly when I issue a replicate command > to it. > > After the last replication, the slave, in solr_home, has a data/index > directory as well as a data/index.20120113121302 directory. > > The /admin/replication/index.jsp admin page reports: > > Local Index > Index Version: 1326407139862, Generation: 183 > Location: /opt/solr/solr_searcher/prod/data/index.20120113121302 > > > So does this mean the index.XXXX file is actually the one currently being > used live, not the straight 'index'? Why? > > I can't afford the disk space to leave both of these around indefinitely. > After replication completes and is committed, why would two index dirs be > left? And how can I restore this to one index dir, without downtime? If > it's really using the "index.XXXXX" directory, then I could just delete the > "index" directory, but that's a bad idea, because next time the server > starts it's going to be looking for "index", not "index.XXXX". And if it's > using the timestamped index file now, I can't delete THAT one now either. > > If I was willing to restart the tomcat container, then I could delete one, > rename the other, etc. But I don't want downtime. > > I really don't understand what's going on or how it got in this state. Any > ideas? > > Jonathan > -- Best regards, Artem Lokotosh mailto:arco...@gmail.com
